civil-devel Mailing List for Civil

On Wed, 28 Feb 2001, Kalle Svensson wrote:

>I did manage to read a little and actually have the energy to digest it.
>Had brought "Design Patterns" and "The UNIX Programming Environment", both
>books that I've tried to read but found boring, difficult or both.  It felt
>good to actually get something out of them this time.

Design Patterns is good. It has become a little overhyped the last few
years, but it can give you a few good ideas nevertheless. I read it when
it was new and it got me into thinking about code in a completely
different way. Another quite funny read is the "Antipatterns" book...

>I agree.
>One thought is that you could make units wait for a keyboard event.  You say:
>Wait for event 1.  Then, when C-1 (or something) is pressed, all units
>waiting for event 1 go ahead.  Just an idea.

This seems like a good way to do it. Is there some game currently out
there that use this way? I haven't played too many of the current PC
games, as I don't have any PC dedicated to playing, so I don't know.

It should not be too hard to do either:

1. activate unit
2. click X to activate a "synchronized" command triggered by Y
3. give orders to the unit
4. client side stores commands linked to trigger Y
5. goto 1 while there are more units to be synchronized
6. trigger YYY
7. set current turn as "issue turn" for all commands stored for trigger Y
8. handle the commands for all units as if they had been given normally

Something like that?

Another way would be to let the player group units, just as in all other
games by selecting them with a rectangle or picking them with Ctrl
pressed.

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

Some cutting and pasting in this one:

Sez Gareth Noyce:
> I've uploaded a couple of misc changes to the website, mainly errata and
> added Kalle to the developers listed on the front page. Hope this is ok
> Kalle!

Well, sure.  But I haven't really done anything yet... :)

Sez Jan Ekholm:
> Well, he's right now chasing camels and climbing pyramids. I'm not
> jealous, we just got 15cm of lovely sweet snow. Well, maybe a little.

Well, it was nice.  Saw lots of old temples.  Nice weather, perhaps a bit
too hot for my taste.  I can't get a tan, I just get burned.
Anyway, the best part was all the service, food, cleaning, that stuff.  And
not having to work.

I did manage to read a little and actually have the energy to digest it.
Had brought "Design Patterns" and "The UNIX Programming Environment", both
books that I've tried to read but found boring, difficult or both.  It felt
good to actually get something out of them this time.

Sez Jan Ekholm:
> On 21 Feb 2001, Mike Earl wrote:
> >Quick thought; I think a handy order might be 'wait' once queuing orders
> >is established.  You could order a bunch of units to 'wait until time X'
> >and then move, and they'd all move at once, which would be very hard to
> >manage otherwise.  Don't know what the interface for this would be,
> >though.
>=20
> Yes, this would be a *good* feature. It does need some thinking about
> before it can be implemented. If you have good ideas about how it could be
> implemented please let me know.

I agree.
One thought is that you could make units wait for a keyboard event.  You sa=
y:
Wait for event 1.  Then, when C-1 (or something) is pressed, all units
waiting for event 1 go ahead.  Just an idea.

OK, time to go to bed.  Work as usual tomorrow.

Peace,
  Kalle
--=20
Email: ka...@gn...     | You can tune a filesystem, but you
Web: http://www.gnupung.net/ | can't tune a fish. -- man tunefs(8)
PGP fingerprint: 0C56 B171 8159 327F 1824 F5DE 74D7 80D7 BF3B B1DD

Quoting Jan Ekholm <ch...@in...>:

> >Excellent idea... How much freedom do we have  
> >the SF server to put an XSLT processor (ie: 
> >4Suite) on? I presume that there would be no 
> >problems...?
> 
> I'm not sure, it would be best to read some of 
> the SF docs, or ask the
> support staff. If they don't like us to install 
> something on our own
> they
> could even kick us out. SF has its bugs, but it 
> has been very useful.

Hmmm, best fire off an email. They may even have 
some PHP stuff to do similar... 

G


-------------------------------------------------
This mail sent through UK Online webmail

On Tue, 27 Feb 2001, Gareth Noyce wrote:

>> Speaking of pages. It should be easy/possible 
>> to create a XSL file that
>> could create some nice HTML from a given 
>> scenario file. This could then
>> be
>> used to extract information about the scenarios 
>> we will have in our
>> (upcoming) central repository on some machine 
>> (say, SourceForge). This
>> was
>> we could always have on the webpages up-to-date 
>> information about the
>> scenarios without any human intervention.
>> 
>> I'll take it as a test project as soon as I 
>> resume learning XSLT. :-)
>
>Excellent idea... How much freedom do we have on 
>the SF server to put an XSLT processor (ie: 
>4Suite) on? I presume that there would be no 
>problems...?

I'm not sure, it would be best to read some of the SF docs, or ask the
support staff. If they don't like us to install something on our own they
could even kick us out. SF has its bugs, but it has been very useful.

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

> Speaking of pages. It should be easy/possible 
> to create a XSL file that
> could create some nice HTML from a given 
> scenario file. This could then
> be
> used to extract information about the scenarios 
> we will have in our
> (upcoming) central repository on some machine 
> (say, SourceForge). This
> was
> we could always have on the webpages up-to-date 
> information about the
> scenarios without any human intervention.
> 
> I'll take it as a test project as soon as I 
> resume learning XSLT. :-)

Excellent idea... How much freedom do we have on 
the SF server to put an XSLT processor (ie: 
4Suite) on? I presume that there would be no 
problems...?

G


-------------------------------------------------
This mail sent through UK Online webmail

On Mon, 26 Feb 2001, Gareth Noyce wrote:

<lots stuffis schnipp>

>I was thinking about this last night. I would be a perfect job for a
>simplified active python page (or similar). You could just bung a
>variable in place of the path declaration in the XML file, and get the
>'builder' to replace this with the users scenario path (this could even
>be passed from the CLI, or figured out by a quick scan of the
>filesys)...

Speaking of pages. It should be easy/possible to create a XSL file that
could create some nice HTML from a given scenario file. This could then be
used to extract information about the scenarios we will have in our
(upcoming) central repository on some machine (say, SourceForge). This was
we could always have on the webpages up-to-date information about the
scenarios without any human intervention.

I'll take it as a test project as soon as I resume learning XSLT. :-)

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

The newst stuff in the CVS now has a "utility" to generate index files
from a directory of scenarios. It is at the end of 'scenario_manager.py',
and can be used like:

	% ./scenario_manager.py directory indexfile 
or

	% python scenario_manager.py directory indexfile

depending on your system. The parameter 'directory' is scanned for all xml
files that are not scenarioindex.xml, and the resulting index is written
to 'indexfile', which should be called 'scenarioindex.xml' if placed in
the scenario-directory.

This could be ripped out into a standalone and more full-featured
management tool some day, but for now it should work. The fact that the
tag <url> in the scenarios is fubar is a problem. I think it should be
removed entirely, and the url/path managed in ScenarioManager internally.
What do you think? It is kind of unnecessary there...

What probably instead should be added is some kind of <authorinfo> tag,
with info about the author of the scenario. This could be:

	* author name
	* email
	* scenario homepage (where find new versions)
	* creation date
	* version
	* other?

Ideas?

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

Me too!


On 26 Feb 2001 09:35:05 +0000, Gareth Noyce wrote:
> 
> > 4. external utility that creates the index. 
> > Player runs when adding new
> >    scenarios. This utility could be extended to 
> > also retrieve scenarios
> >    through ftp, http (urllib does that for us).
> 
> This would be my choice. The util can be 
> explicitly run on install, called from the 
> scenario editor when required, and used by the 
> user when they obtain new scenarios. Or, as you 
> state, used to /get/ new scenarios and integrate 
> them...
> 
> No.4 has my vote...
> 
> G
> 
> 
> -------------------------------------------------
> This mail sent through UK Online webmail
> 
> _______________________________________________
> Civil-devel mailing list
> Civ...@li...
> http://lists.sourceforge.net/lists/listinfo/civil-devel
> 

> 4. external utility that creates the index. 
> Player runs when adding new
>    scenarios. This utility could be extended to 
> also retrieve scenarios
>    through ftp, http (urllib does that for us).

This would be my choice. The util can be 
explicitly run on install, called from the 
scenario editor when required, and used by the 
user when they obtain new scenarios. Or, as you 
state, used to /get/ new scenarios and integrate 
them...

No.4 has my vote...

G


-------------------------------------------------
This mail sent through UK Online webmail

Quoting Jan Ekholm <ch...@in...>:

> >Sounds like a fairly nice thing to do, and not 
> >too hard...
> >Realistically, 
> >when the scenario editor is completed, it 
> >should do this anyway?
> 
> Probably. Either by itself (if the user wants 
> to) or then the user must
> manually run the tool. Every new half-finished 
> scenario should not be
> integrated as soon as it is saved, as that 
> could lead to players
> choosing
> scenarios that are not yet ready for use.

Yeah, in that case, a simple button: build 
scenarios, would suffice for explicit inclusion, 
or an automated build when a scenario is 
complete...

> >If we always have a known scenario dir (as we 
> >do at the moment) then 
> >couldn't we get around the problem by using 
> >relative paths most of the
> 
> >time? ATM it's a /home/chakie/... affair. I've 
> >just made everything 
> >../scenario/... in the files on my install and 
> >this seems to be working
> >OK.
> >
> >I suppose it's safer to have a script that 
> >configures the paths
> >ultimately.
> 
> This should work, yes. It of course assumes 
> that everything is launched
> from the src/ directory (or some other dir at 
> the same depth). There
> must
> (I think) be some kind of "installation" script 
> sooner or later that
> configures the game when installed.

I was thinking about this last night. I would be 
a perfect job for a simplified active python page 
(or similar). You could just bung a variable in 
place of the path declaration in the XML file, 
and get the 'builder' to replace this with the 
users scenario path (this could even be passed 
from the CLI, or figured out by a quick scan of 
the filesys)... 

Simple variable substitution...

G
G

-------------------------------------------------
This mail sent through UK Online webmail

On 25 Feb 2001, Mike Earl wrote:


>Ok, the map module now has pointToHex and hexCenter methods for finding
>the hex coordinates of a map point and the map coordinates of a given
>hex's center.  

Nice chunks of really gory geometry handling! If all that works I am
impresed. Good work, Mike.

>Also, I added a util.geometry module for some stuff I needed for the hex
>calculation.  There *ought* to be an easier way to do this, but I'll
>need all that infrastructure for the LoS terrain stuff anyhow...

You mean avoiding having a separate module, or just cleanups? I think it
is good to break up potentially useful stuff in separate modules. Keep it
there if you like to have a separate module.

>One bug in the basic LoS: after all units are loaded, but before the
>first real turn, it should run calcView() on each unit.  I don't know
>where the right place for that would be?  Right now units which start
>the game in sight range don't see each other until someone moves.
>Hmmm... now that I think about it, you could probably do it in unit
>initialization and have it work,  even if all units aren't loaded at
>once, because the ones loaded later will notify the early ones "Hey, I
>see you now, check if you see me."   

Or it could be put in NewGame.setupScenario(). It is designed to be run
when a scenario has been loaded and right before the game starts. The docs
for it even says that visibility should be set there. Right now it just
sets all enemies to invisible and own units to visible. Could we run
calcView() on each unit there?

>The code is pretty much in place to tackle the terrain/LoS integration.
>Not today, though.   I don't think I've done so much geometry in 10
>years; I have to go watch kung-fu movies now to rebalance my brain.  :)

You've done a really good work. I had never really thought about using
three parallell lines for the calculations, but as you describe it, it
seems like a really good way. And, it works too.

>To some extent it is the install-config problem again; I don't know if
>there is a good cross-platform way to do that (except maybe for the
>relative-to-current-working-dir kludge the gfx and everything else
>uses).  As far as the scenario indexes go, though: You could maybe read
>it, then scan (local only?) directories for scenarios not included, and
>rebuild the index only if you were missing some?

Maybe it should be run once when the game is installed? And if the player
adds new scenarios the player would be forced to run the script once. Or,
could we rely on the modification date of the scenarioindex.xml file and
use it to see which scenarios are newer than it? This is maybe not too
reliable, and could be hard to get crossplatform.

Options so far:

1. leave as is (player does manual editing of index file)

2. waste the index file, server reads all files upon startup

3. scenario editor creates index. Does not work if a scenario is just
   copied to the directory

4. external utility that creates the index. Player runs when adding new
   scenarios. This utility could be extended to also retrieve scenarios
   through ftp, http (urllib does that for us).

5. rely on file dates and have server rebuild index when new scenarios
   have appeared

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

On Sun, 25 Feb 2001, Gareth Noyce wrote:

>At 12:26 PM 2/25/01, you wrote:
>
>>I looked at the scenario MikeE had done, and was about to integrate it
>>into the 'scenarioindex.xml' file in CVS, but then I started thinking
>>about it a little more. The paths in the idnex file are obviously mostly
>>suitable for *my* environment, so everyone else who wants to test must
>>hack the paths. This is of course not good.
>
>Yup, this has been noted at this end! ;-) I have a habit of keeping the set 
>that I fixed in a seperate dir, then moving them over when I want to play...

I will do something about it, unless someone else races me and does it
first. :-) Testing must be easy to do, otherwise it does not get done and
development isn't fun.

>>Why not build a simple script that rebuilds the scenario index file? It's
>>simple and all needed code already exists, it must juts be ripped out and
>>assembled into a small utility. That would mean that the script could be
>>run when a new scenario has been added to the scenarios/ directory, thus
>>avoiding handediting of the scenarioindex file.
>
>Sounds like a fairly nice thing to do, and not too hard... Realistically, 
>when the scenario editor is completed, it should do this anyway?

Probably. Either by itself (if the user wants to) or then the user must
manually run the tool. Every new half-finished scenario should not be
integrated as soon as it is saved, as that could lead to players choosing
scenarios that are not yet ready for use.

>>Or the server could read all scenario files upon startup, thus making the
>>entire file unnecessary. The drawbak here is that the server starts
>>slower, of course, as it must start parsing the full files, and not just
>>parse a small index file. How much slower, I don't know.
>
>What about when there are hundreds of scenarios? Ok, this isn't a problem 
>at the mo, but you can easily envisage a time when a group of players have 
>made 10s of scenarios, and this gets shared with others etc...
>
>I think the scenario index file is a Good Thing and should be kept.

You are probably right. It must justget automated and easier to use.
Reading in 100:s of scenarios *will* take some time, maybe too much.


>If we always have a known scenario dir (as we do at the moment) then 
>couldn't we get around the problem by using relative paths most of the 
>time? ATM it's a /home/chakie/... affair. I've just made everything 
>../scenario/... in the files on my install and this seems to be working OK.
>
>I suppose it's safer to have a script that configures the paths ultimately.

This should work, yes. It of course assumes that everything is launched
from the src/ directory (or some other dir at the same depth). There must
(I think) be some kind of "installation" script sooner or later that
configures the game when installed.

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

LoS update:

Ok, the map module now has pointToHex and hexCenter methods for finding
the hex coordinates of a map point and the map coordinates of a given
hex's center.  

I should maybe produce documentation on the pointToHex, but it would
almost need pictures to be useful.  The basic idea is you have 3 sets of
parallel lines that (between) them, chop the hexes into 6 triangles
each.  By figuring out which 2 lines in each set a point falls between,
you know what triangle, and thus what hex it's in.  It's actually not
too bad in the common case, but the code looks heniously complex because
of a lot of ugly little special cases (eg, the point is the exact center
of a hex, or on an edge, or on a vertex).  It seems to work, though.
The check_los now prints out the hex clicked, as well.

Also, I added a util.geometry module for some stuff I needed for the hex
calculation.  There *ought* to be an easier way to do this, but I'll
need all that infrastructure for the LoS terrain stuff anyhow...

One bug in the basic LoS: after all units are loaded, but before the
first real turn, it should run calcView() on each unit.  I don't know
where the right place for that would be?  Right now units which start
the game in sight range don't see each other until someone moves.
Hmmm... now that I think about it, you could probably do it in unit
initialization and have it work,  even if all units aren't loaded at
once, because the ones loaded later will notify the early ones "Hey, I
see you now, check if you see me."   

The code is pretty much in place to tackle the terrain/LoS integration.
Not today, though.   I don't think I've done so much geometry in 10
years; I have to go watch kung-fu movies now to rebalance my brain.  :)

scenarios:

To some extent it is the install-config problem again; I don't know if
there is a good cross-platform way to do that (except maybe for the
relative-to-current-working-dir kludge the gfx and everything else
uses).  As far as the scenario indexes go, though: You could maybe read
it, then scan (local only?) directories for scenarios not included, and
rebuild the index only if you were missing some?

- mikee

At 12:26 PM 2/25/01, you wrote:

>I looked at the scenario MikeE had done, and was about to integrate it
>into the 'scenarioindex.xml' file in CVS, but then I started thinking
>about it a little more. The paths in the idnex file are obviously mostly
>suitable for *my* environment, so everyone else who wants to test must
>hack the paths. This is of course not good.

Yup, this has been noted at this end! ;-) I have a habit of keeping the set 
that I fixed in a seperate dir, then moving them over when I want to play...

>Why not build a simple script that rebuilds the scenario index file? It's
>simple and all needed code already exists, it must juts be ripped out and
>assembled into a small utility. That would mean that the script could be
>run when a new scenario has been added to the scenarios/ directory, thus
>avoiding handediting of the scenarioindex file.

Sounds like a fairly nice thing to do, and not too hard... Realistically, 
when the scenario editor is completed, it should do this anyway?

>Or the server could read all scenario files upon startup, thus making the
>entire file unnecessary. The drawbak here is that the server starts
>slower, of course, as it must start parsing the full files, and not just
>parse a small index file. How much slower, I don't know.

What about when there are hundreds of scenarios? Ok, this isn't a problem 
at the mo, but you can easily envisage a time when a group of players have 
made 10s of scenarios, and this gets shared with others etc...

I think the scenario index file is a Good Thing and should be kept.

>Ideas? This is something that nevertheless must be done eventually, last
>chance is when actually installing the server at some "customer".

It sounds almost like there are two problems here. Configuring the paths 
when a user installs the game, and then updating scenarios that are passed 
from disparate players.

If we always have a known scenario dir (as we do at the moment) then 
couldn't we get around the problem by using relative paths most of the 
time? ATM it's a /home/chakie/... affair. I've just made everything 
../scenario/... in the files on my install and this seems to be working OK.

I suppose it's safer to have a script that configures the paths ultimately.

G


-- 
"Computer games don't affect kids. I mean if Pacman had affected us as
kids, we'd all be running around in a darkened room munching pills and
listening to repetitive music." -- Unknown
--

I looked at the scenario MikeE had done, and was about to integrate it
into the 'scenarioindex.xml' file in CVS, but then I started thinking
about it a little more. The paths in the idnex file are obviously mostly
suitable for *my* environment, so everyone else who wants to test must
hack the paths. This is of course not good.

Why not build a simple script that rebuilds the scenario index file? It's
simple and all needed code already exists, it must juts be ripped out and
assembled into a small utility. That would mean that the script could be
run when a new scenario has been added to the scenarios/ directory, thus
avoiding handediting of the scenarioindex file.

Or the server could read all scenario files upon startup, thus making the
entire file unnecessary. The drawbak here is that the server starts
slower, of course, as it must start parsing the full files, and not just
parse a small index file. How much slower, I don't know.

Ideas? This is something that nevertheless must be done eventually, last
chance is when actually installing the server at some "customer".

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

On 23 Feb 2001, Mike Earl wrote:

<earlier comments>

>    - visibility is currently based only on distance 

Good enough for a first rough test. We should decide what data needs to be
available about each type of terrain/icon, and build up a lookup table (or
said fancier: database) with the needed data for all ~200 icons. Info such
as how easy units can pass through it, visibility factors, slopes, cover
etc.

>    - client GUI doesn't handle multiple sides very well
>        (clicking back and forth causes crashes, all look the same)

Should be fixed now, I think. The two sides should eventually have
different icons, which should make them look different.


--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

On 24 Feb 2001, Mike Earl wrote:

>On 24 Feb 2001 14:17:54 +0200, Jan Ekholm wrote: 
>> >Still dinking around, just ran across an oddity; if you have a scenario
>> >with units of 2 players, clicking on an enemy unit and then back to your
>> >own crashes the client.  
>> It's not entirely clear, but should be something simple. I've never really
>> tried games with units of both players... You you happen to have an easily
>> pasteable stack trace too?
>> 
>> Do you have such a scenario? Could you add it to CVS? I'll fix the bug.
>
>
>Ok, will add that scenario to CVS momentarily.  (It's just a couple of
>the others cut-and-pasted together).  

As are most of the others too. Some of the old ones may not even be valid
anymore due to scenario format changes.

>I sort-of understand what's happening but was having strange troubles
>trying to fix it myself - it seems like the switch from state own-unit
>to enemy-unit is creating the enemy-unit-selected state with the wrong
>parameters.

Yep, when creating a new state OwnUnit or EnemyUnit, the currently active
unit must be given to the constructor. It was missing, so it got only 1
parameter, and not the expected 2. The same bug should have occurred if
you had an own unit and then activated an enemy, as it too lacked the
parameter. Fixed and checked in.

>  File "state/enemy_unit.py", line 152, in activateUnit
>    newstate = state.own_unit.OwnUnit () 
>TypeError: not enough arguments; expected 2, got 1

>Also, for some reason I can't get the los_check state to activate.  It
>should just be select a unit, type "l", yes?  Hrm.

Yep. Works for me at least. I click a unit, type 'l' and get the following
debugging printed out:

event_loop: new state: check_los

There is currently no other visual impact of the state, but there should
be a custom cursor that is activated. Left-clicking the shows for
instance:

CheckLos.handleLeftMousePressed: los from 270,280 to 429,184 

Pressing 'Escape' terminates the state and returns to OwnUnit.

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

On 24 Feb 2001 14:17:54 +0200, Jan Ekholm wrote: 
> >Still dinking around, just ran across an oddity; if you have a scenario
> >with units of 2 players, clicking on an enemy unit and then back to your
> >own crashes the client.  
> It's not entirely clear, but should be something simple. I've never really
> tried games with units of both players... You you happen to have an easily
> pasteable stack trace too?
> 
> Do you have such a scenario? Could you add it to CVS? I'll fix the bug.


Ok, will add that scenario to CVS momentarily.  (It's just a couple of
the others cut-and-pasted together).  I sort-of understand what's
happening but was having strange troubles trying to fix it myself - it
seems like the switch from state own-unit to enemy-unit is creating the
enemy-unit-selected state with the wrong parameters.  

UnitState.setSelectedUnit: 1 selected units
Traceback (most recent call last):
  File "civil.py", line 165, in ?
    main ()
  File "civil.py", line 159, in main
    event_loop ()
  File "event_loop.py", line 153, in event_loop
    newstate = currentState.handleEvent ( event )
  File "state/basestate.py", line 74, in handleEvent
    newstate = self.handleLeftMousePressed ( event )
  File "state/enemy_unit.py", line 113, in handleLeftMousePressed
    return self.activateUnit (globalx, globaly)
  File "state/enemy_unit.py", line 152, in activateUnit
    newstate = state.own_unit.OwnUnit () 
TypeError: not enough arguments; expected 2, got 1

Also, for some reason I can't get the los_check state to activate.  It
should just be select a unit, type "l", yes?  Hrm.

On 23 Feb 2001, Mike Earl wrote:

>Still dinking around, just ran across an oddity; if you have a scenario
>with units of 2 players, clicking on an enemy unit and then back to your
>own crashes the client.  I'll look at that after I have LoS sort-of
>working unless the answer is clear to somebody else?

It's not entirely clear, but should be something simple. I've never really
tried games with units of both players... You you happen to have an easily
pasteable stack trace too?

Do you have such a scenario? Could you add it to CVS? I'll fix the bug.

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

On 23 Feb 2001, Mike Earl wrote:

>I've got to quit responding to my own mail...
>
>
>Never mind, got CVS working, committed changes.  Woo!  Haven't
>implemented check_los yet, will look at that next.

It pays to read *all* mails before doing something. I was just applying
the patch when I glanced at the last mail you wrote (ssh working). :-)

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

I've got to quit responding to my own mail...


Never mind, got CVS working, committed changes.  Woo!  Haven't
implemented check_los yet, will look at that next.

Arg.  Well, I don't have ssh up and running on my machine, and so far it
resists my efforts to find and install it.  I'll fight that tomorrow.
Thus no write CVS access for me.

The following code works, but:

    - visibility is currently based only on distance 
    - client GUI doesn't handle multiple sides very well
        (clicking back and forth causes crashes, all look the same)

The basic idea seems to work, though.  Tacked on following is a patch;
sorry about that, but it isn't long, and I won't want to drift far from
the main tree, or go much further before somebody who has coded python
before looks at this.  Have a look and apply if it looks good!

Terrain and LoS checking functions next...

########## output of "diff -Naur" follows, times in UTC
######################


--- civil/src/unit.py	Thu Feb 22 16:53:25 2001
+++ mikee-civil/src/unit.py	Sat Feb 24 02:09:19 2001
@@ -7,6 +7,8 @@
 from modifier      import Morale, Fatigue, Experience
 from leader        import Leader
 from organization  import Organization
+# necessary for LoS
+import scenario
 
 # define the posisble unit types
 INFANTRY  = 0
@@ -62,8 +64,10 @@
         # no weapon yet
         self.weapon = None
         
-        # by default a unit is visible
+        # by default a unit is visible, sees no-one, sight-range of 100
         self.visible = 1
+        self.sees = {}
+        self.sightRange = 100
 
         # by default the unit has no commands enqueued
         self.commands = {}
@@ -140,6 +144,43 @@
         local player. No track is kept wether the enemy sees units of
the local player."""
         return self.visible
 
+    def calcViewSingle (self, unit):
+        """Recalculates LoS/Visiblity from us to them.  Based only on
distance right now."""
+        sightSquared= self.sightRange ** 2
+        x, y = self.getPosition ()
+        x2, y2 = unit.getPosition ()
+        # square roots are expensive, so don't bother to take the
+        # root of each side for the actual distance, just compare.
+        if (x-x2)**2+(y-y2)**2 < sightSquared:
+            self.sees[unit.id]=1
+        else:
+            if self.sees.has_key(unit.id):
+                del self.sees[unit.id]
+        if len(self.sees) == 0 and
self.getOwner()!=scenario.local_player_id:
+            self.setVisible(0)
+        else:
+            self.setVisible(1)
+        return self.sees.has_key(unit.id)
+        
+
+    def calcView (self):
+        """Recalculates all lines-of-sight for this unit.  Not sure if
it really belongs here (where
+        else instead?) but no place better to put it for now at
least."""            
+        # loop over all units in the map
+        for unit in scenario.units.values ():
+            # is the unit visible
+            if unit.getOwner () == self.getOwner ():
+                # if on our side, never mind.
+                continue
+            # Ok, can I see you already?
+            if self.sees.has_key(unit.id):
+                wasVisible = self.sees[unit.id]
+            else:
+                wasVisible = 0
+            if wasVisible != self.calcViewSingle(unit):
+                # my visiblity of them changed, they must recalculate
too
+                unit.calcViewSingle(self)
+            
 
     def setVisible (self, visible):
         """Sets a new visibility value for the unit. A value of 0 means
not visible, all other mean
--- civil/src/protocol/move.py	Thu Feb 22 16:53:27 2001
+++ mikee-civil/src/protocol/move.py	Fri Feb 23 02:52:50 2001
@@ -184,6 +184,7 @@
         else:
             # set the new position
             unit.setPosition ( ( self.targetx, self.targety ) )
+            unit.calcView ()
 
  
     def toString (self):

Still dinking around, just ran across an oddity; if you have a scenario
with units of 2 players, clicking on an enemy unit and then back to your
own crashes the client.  I'll look at that after I have LoS sort-of
working unless the answer is clear to somebody else?

- mikee

> It does not matter too much, I can do it too, 
> as long as I know exactly
> which files should be removed. Basically all 
> files that are in both
> gfx/
> and gfx/dialogs OR gfx/periphery ?

Yup. Anything that's echoed between the three 
dirs... Basically, it should just be butt-, 
dialog- and the splash- prefixed stuff...

/gfx should then contain, next.png, previous.png, 
objective.png, selection.png, status.png(?) and 
all your mini-*.png bits. 

Sorry about the hassle. I shouldn't have been 
lazy in the first instance...

[mental note: move cvs to linux...]

> :-) So your house is now fully networked 
> and "Internet-ready"?

No, but that's this weekend's mission. We have 
three seperate development servers distributed 
around -- these are now in one house -- so we 
have to consolidate them, network our desktops, 
configure the OBSD firewall for the new network, 
chuck our mp3 server on (!) and drop CAT5 around 
the house. Not to mention move my 'collection' of 
machines somewhere sensible. Then I'll move my 
civil developments onto my Linux server, move my 
code off the PCs/Sparcs and put them somewhere 
sensible (prob linux server2) and tie the network 
up to our commercial internet server in London so 
we can get on with the development of 
Sotonians... 

It's going to be one hell of a weekend. I'll be 
impressed if we get the network cable dropped and 
the servers consolidated... ;)

G


-------------------------------------------------
This mail sent through UK Online webmail

On Fri, 23 Feb 2001, Gareth Noyce wrote:

>> > Moving a file is basically:
>> > 
>> > 1. move file to new directory or new name (if 
>> you copy the file, delete
>> >    the old)
>> > 2. cvs add <new file>
>> > 3. cvs rm <old file> (which should not exist 
>> anymore)
>
>Ok, looked this one up. You do still have to rm 
>the file from winCVS, it doesn't just handle it. 
>However you need TCL installed in order to access 
>the CVS tree through it's little "command 
>window". This isn't something I've put on my 
>windows box, as I tend to use the sparc for such 
>code...

It does not matter too much, I can do it too, as long as I know exactly
which files should be removed. Basically all files that are in both gfx/
and gfx/dialogs OR gfx/periphery ?

>Sorry for the hassle. I may well move everything across to my Linux
>server after the mighty cat5 drop this weekend, that should remove most
>of the hassles I seem to cause!

:-) So your house is now fully networked and "Internet-ready"?

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams