colossus-developers Mailing List for Colossus (Page 227)

Le dimanche 27 janvier 2002, =E0 01:13 AM, David Ripton a =E9crit :

> I checked in the code to flip images on the fly, and made a new build.
>
> If nobody reports any problems for a few days, I'll delete=20
> i_*.gif from the cvs tree.

This does not seem to work under the JVM in MacOS X ; nothing
is displayed. I can still click on the "Chit" (the destination
Hex are highlited in red), but they aren't shown, either off-
or on-board. This makes the game unplayable :-(

After looking at the code, it seems you invert the Chit by
making the destination rectangle backward. Is it explicitely
supposed to work (i.e. a bug in the OSX JVM), or is it
"implementation-dependant" ? In the latter case, you could
use the same trick as I wanted to use for the overlay :
draw the Image in a BufferedImage, and use an AffineTransformOp
to rotate that 180=B0. This should work everywhere, but will
will undoubtly be slower.

Sorry to be the bearer of bad news,

--
romain

Le vendredi 25 janvier 2002, =E0 08:16 PM, David Ripton a =E9crit :

> Sounds good, as long as we avoid complex variant code in the=20
> main branch until networking is stable to keep me from going=20
> completely insane.
>
> Ditching the static array is great, though any server-side code=20
> that can only access the map because of its staticness needs a=20
> network-safe way to get at the info.
> No direct references from server-side classes to client-side=20
> classes allowed (except for the proxy refs in Client/Server) --=20
> that's what I've spent months untangling.


Well, I've commited a bunch of changes to add a class "VariantSupport"
in client. it ain't really new code, it's mostly refactoring of
the old Variant code scatered in GetPlayers and some other places.

Now almost everything is in VariantSupport ; it loads the 'VAR'
file, hold the name of the others files, and hold the list of
directories to search for the various data. I've added a 'DEPEND'
key to the VAR file, so that a Variant can use data from another
variant. The 'Default' directory is also searched in all case.

Unfortunately, there's some references to VariantSupport in
server/Creature.java and server/Game.java, but they simply
replace prior references to client/getPlayers. Also,
the output of VariantSupport::<function> is exclusively
String or List of String, so networking that shouldn't be
too much of a problem (I hope !).

--
romain

David Ripton wrote:

> Peter Becker wrote:
>
> > While playing different versions of Colossus I encountered some bugs and
> > other issues, some of them seem to be fixed by now but I will enlist
> > them anyway. Those are tagged with an asterisk instead of a dash. Please
> > tell me how you want further RFEs, I do this per mail since it is quite
> > a long list and I have to use a modem connection at the moment, but I
> > can use the SF tracker or whatever you want for the forthcoming ones (I
> > always find at least some feature requests ;-) ).
>
> Thanks for the extensive bug reports.
>
> The SF bug tracker is the best way to report individual bugs because
> everyone can see the reports, which greatly reduces duplicate
> submissions.

I know, I maintain some SF projects myself ;-) But...

> Most emailed bug reports just go to me (because my email
> is the only one on the web page -- I don't publish other people's emails
> unless they ask me to for privacy/spam reasons), which is non-ideal.  We
> have a testers list designed for bug reporting, but it's completely
> inactive right now.  (I suspect it will become used once we have
> networking in the enabled-but-twitchy state.)
>
> We've been making big changes lately, so a lot of the bugs you reported
> were created recently and then fixed a few days later.  Most of the bugs
> in your list are already known.  I need to start using the SF bug
> tracker more myself, to show bugs that are already known.  My kingdom
> for a fast net connection...

.. I currently suffer from the same problem. Last year I was working at a uni
and the tracker where cool. Now it is a modem and I'd like something which
integrates email (like GNATS or similar systems).

> > - battlefields appear behind masterboard: there is a short dialog
> > popping up, then the battlefield has focus but is not risen.
>
> I broke this intentionally, when removing direct server-side control of
> the GUI.  I need to fix it on the client side.  I prefer moving frames
> down to moving them up, because programs that keep jumping to the top
> are really annoying when you're trying to multitask.

But when a battle starts I always want to go to the battlefield. And since the
focus is already in the lower window I have to change focus twice to raise it.

> > - saving game while combat creates corrupt savegame
>
> Did you get errors on save, or only when you tried to load the file
> later?

Only on loading.

> The latter is a known problem -- I got battle loading correct
> once, but it has decayed badly.  Once the client/server refactoring is
> done and the public methods of the proxy classes are clean and stable, I
> will make an attempt at getting loading in the middle of battle working.
>   We do a lot of initialization at the start of phases, so loading in
> the middle of phases requires extra code.

No worries. What about just disabling the feature while in combat mode?

> > - program does hardly respond when playing alone (i.e. all human players
> > died), menu not available
>
> Even with AI delay turned up a bit?  We use a timer to schedule the next
> advancePhase(), and the GUI should be fully responsive during that
> interval.  Maybe we need to force a repaint at the time the phase
> advance is scheduled.

I don't use AI delay. Then the menues don't even appear.

[...]

> > Here are some feature wishes from that time:
> > - troop summary for players would be nice (optional), maybe some graphs
>
> Need more details about what you want.  Probably won't happen soon
> unless it's really easy.
>
> > - what about PBM feature? Is sending savegames possible (what about
> > combats)? Could this be integrated in game?
>
> PBEM by savefile sharing is not going to happen, because I'm working on
> realtime cheat-proof client-server networking instead.  (Of course you
> can email savefiles around as a stopgap if you really want.)

Client/server means synchronous play while PBEM is asynchronous -- unless you
do some kind of delayed messaging on the server side (similar to IMs).
Actually this would be really cool since the game could be paused at any time
and go back and forth between (nearly) synchronous and asynchronous operation.

The savegames won't work if they break in combats. But it is not really
important for me, just an idea.

> > - animation would be cool: moves, recruits, etc. I find it pretty hard
> > to follow the game. And the option to see the contents is limited, one
> > can remember more information by oneself, e.g. if a known army splits
> > and you attack one part, you know the contents of the others.
>
> I'm going to add display of recent enemy recruits on top of their
> stacks.

Sounds cool. I still would like some fade-in/fade-out for this, but that's not
really important.

> Move animation could easily be handled with a configurable
> delay between AI moves instead of just between phases.
>
> Remembering enemy stack contents that have been seen and are known not
> to have changed is a trivial problem.  Predicting splits and then
> adjusting predictions when they're shown to have been wrong is a more
> fun problem.  I'm going to do client-side tracking of stack contents
> soon (so if you flee from a stack you'll be able to see it but others
> will not), and then AI stack prediction, which humans can optionally use
> as an aid.  (It's not cheating because the info is all in the log anyway
> and you can't really keep faraway people from taking notes -- it just
> reduces the need to scroll back, which should help people play faster.)

I completely agree, also I probably would add a turn-off option for the people
who might consider it more "pure" without. With the feature described above it
should be possible to follow the muster processes anyway, I didn't like to
check all legions at the beginning of my turn.

[...]

> > - what about a full XML protocol for later analysis of games?
>
> The client/server protocol will be custom plain text (a la SMTP), not
> XML.  It will be usable for tracking.  There are valid reasons not to
> use XML for everything -- our protocol will be more compact, more
> human-readable, easier to parse because it's so small, etc.  And no XML
> parser is included in JDK 1.2 / 1.3.  See protocol.txt for a rough draft
> -- it'll change a bit.

I had a look at some of your file formats / protocols. That's ok for me (I
wrote a lex/yacc compiler frontend myself), although I tend to do nearly
everything in XML by now. But we don't have to discuss the pros and cons here,
it could take longer ;-)

> We may eventually add some XML exports for compatibility with other
> programs.  Our savegame format is really ugly and unreadable and should
> be XML (because it's hierarchical enough that the tags are helpful
> rather than baggage), but I want to hold off until JDK 1.4 is ubiquitous
>   because I don't want to include a bulky XML parser in Colossus or make
> users install one.

Anything that might be of use for other people should be in XML IMO. If you
export the game protocol as XML people could easily get treeviews (using a
generic XML editor/viewer) and HTML or other markup (using XSLT). Here the
advantages are higher than the costs (which aren't high IMO anyway -- if you
want to save space go XDR or ASN.1 ;-) ).

> > Comments on the development version:
> > - easy to access instructions how to build Colossus would be useful
> > (Ant, JavaCC). I found the comments in the build file only after I
> > figured out how to get JavaCC (I use Ant anyway).
>
> Yes, will do.  We need a developer subdirectory under docs.

Go on the website, that is where I (and presumably all others) look first. I
can recommend another SF project for your website: http://xweb.sf.net
(shameless plug *g*).

> > - TitanX.gif should be rendered -- I always dislike fixed numbers. On
> > the other hand there is a limit for the experience at least in the
> > standard version.
>
> You mean the numbers on the chits should be rendered on the fly?  Tried
> it; looks ugly.  You just can't guarantee precise enough cross-platform
> font sizing in Java.  (If I'm wrong, someone show me.)

You are probably right. It is just that I dislike fixed limits ;-)

> However, on a related matter I would like to revisit flipping images
> programatically.  Back when Colossus ran under JDK 1.1 there wasn't a
> good non-distorting pixel-swapping image-flipper in the API, and I
> didn't feel like writing it myself, so I just used two images.  One of
> the 1.2 APIs probably does what we want, and if so we should use it and
> ditch all the i_ images.

Images in Java suck (as many other things) :-(

> > Now we switch to a CVS version, checked out about a week ago
> > (2002/01/17):
> > - if two Titans are alone on the BF, the attacker will not attack, thus
> > loose
>
> The attacking AI takes way too many time losses and needs to blitz more,
> but again AI tweaking that doesn't directly help the networking effort
> is off my list for now.  Someone else is welcome to pick it up.

It seems to be ok by now, a single Titan seems to attack in round 5 or 6.

> > And now a CVS version from yesterday:
> > - AI did move once both armies with a roll of one in the first turn, but
> > did not muster (sorry, didn't think about copying the command line
> > output at that time)
> > - AI had once only Titan left in an army, moves into towers, musters the
> > last 3 or 4 Warlords and then stops mustering completely (even though
> > moving into towers)
>
> Were other tower creatures exhausted?

No.

> We have code to keep scooby
> snacks from uselessly recruiting crap that'll just feed enemies more
> points, but Titan stacks are supposed to be exempt.

And I wouldn't recruit a Warlock if I have no normal creatures in the stack.

[...]

> > - I dislike the new carry over dialog: too much text at once. I guess a
> > nice way would be a spin control for the target number, where the
> > possible targets are highlighted/marked on the battlefield.
>
> I don't like it either, but I needed to refactor carries and strike
> penalties to eliminate modal server->client calls for networking, and
> carry cursors were causing strange problems, so I decided to ditch the
> carry UI, pass the correct information, and then whip up a very quick UI
> using the information.  In theory we should now be able to improve the
> carry UI *entirely on the client side*.

I'll wait.

> > - the game feels far more sluggish than before (still ok, but slower)
>
> Agreed.  In particular, the first recruit of the game is slow.  And I
> tried running an ExtTitan game on a pretty fast machine (800 MHz Athlon,
> 256MB) last night, and it just bogged forever during startup.  (I was
> multitasking the machine, though.  And I didn't want to interrupt the
> other tasks.)
>
> I need to spend some time with a profiler to find out exactly where some
> of the performance bottlenecks are, fix unnecessarily slow code if
> possible, and see if we can start some initialization before it's needed
> in a worker thread to improve perceived startup performance.
> Unfortunately the masterboard is needed at the beginning, so there's not
> much we can do to hide its initialization cost, except maybe a splash
> screen.
>
> Unfortunately jprof is kind of icky to use, and OptimizeIt! is a bit
> expensive for my tastes.  Does anyone know of a good cheap Java
> profiler, or even just a good wrapper around jprof?  (Something
> analagous to the free JSwat debugger.)

That's something I am looking for, too. Didn't really search, though.

Since you seem busy enough, are you interested in some feedback on the AI? I
made a copy of stdout when the AI stayed forever in 2000 (Tundra) with a Titan
and some Angels/Warlocks.

And don't get all the feedback wrong, it is just thinking aloud ;-) I find the
game already far too enjoyable...

   Peter

David suggested me some stuff on the future of the Variants.

Here's my personal thoughts on the subject, partially
answering him.

1) Moving more loading code to ImageLoader after renaming it
   ResourceLoader seems almost madatory to me ; that way,
   we will be able to load variant from local filesytem,
   JNLP or a JAR file. We will also be able to look
   in the Default directory for the datafiles, so variants
   can share files.

2) I prefer to keep the variants in separate directory ; mixing
   them would prevent multiple Creature or Battlelands by the
   same name.

3) As we can't browse inside the JAR file, I suggest moving the
   'Load Variant' button to three objects:
   # 'load standard variant', a menu that would display the
     list of variant (including 'Default') in the JAR file
   # a text field to display the current variant choosen
   # the 'load variant' button to load an external variant
     (in the filesystem).

4) To give more flexibility to Variant and variant author,
   we should create a 'server/Variant' class, that would
   hold the variant data, i.e. the file names at the moment,
   and more in the future.


point 4) would allow for more interesting customization
of colossus in the future. My idea is to have a function
that would look like :

Object createVariantObject(String className, List parameters)

that would create a new object for the class 'className',
_or from the class extending className defined in the Variant_.
Java permits that thanks to the various Class/ClassLoader/
Constructor... class.

The first candidate is obviously 'GUIBattleHex', so that a
variant author could add Hazard without hacking Colossus
directly. Badlands and the lake could do something like

public String getTerrainName()
{
    switch (getTerrain())
    {
	case 'l':
	   return "Lake";
	default:
	    return super::getTerrainName();
    }
}

Same goes for other functions.

Of course, we first need to get rid of the BattleHex
static array in HexMap, as we must ensure that all
created Hex are from the new Class.

What do you folks think ?

-- 
DOLBEAU Romain               |   I have lost the will to live           
ENS Cachan / Ker Lann        |    Simply nothing more to give           
Thesard IRISA / CAPS         |       -- Metallica,                      
dol...@cl...    |            'Fade to Black'

> > Jerry Reiger sent some nice replacement images for ExtTitan.
> > (Everything but the Ent, including separate chits for original Titan
> > creatures with upgraded power in ExtTitan.)  I checked them into CVS,
> > but haven't had a chance to test ExtTitan with them yet.

Apparently, something went wrng somewhere : there's none of the actually
used new Creatures (Chimera, Jabberwock, ...), they're in the Attic ?!?

> BTW, I believe ExTitan isn't even 20x10, I only forgot to put the "real"
> size (as long as the value are >= what's needed it works, it just wastes
> memory :-( )

It's really 20x10 after all, only it doesn't use the first column, so
the parity is right. It's ugly as sin, but the only solution I see would
be to add a third integer, "parity", that would give the parity of the
board. Regular would be 0, ExTitan (19x10) would be 1. Simply add that
to the sum of X and Y, and then you can compute the inversion of the
Hex.

-- 
DOLBEAU Romain               | I tell you to enjoy life,
ENS Cachan / Ker Lann        |  I wish I could
Thesard IRISA / CAPS         |        but it's too late.
dol...@cl...    |  -- Black Sabbath, 'Paranoid'

> (I tried sending this message to the dev list, but it got bounced 
> because the SF list manager doesn't like something about my email config
> today, so I'll just send it to you.)

CC:ed the list.

> Jerry Reiger sent some nice replacement images for ExtTitan.
> (Everything but the Ent, including separate chits for original Titan
> creatures with upgraded power in ExtTitan.)  I checked them into CVS,
> but haven't had a chance to test ExtTitan with them yet.

I had just made the upgraded Creature, but Jerry's are nicer :-)
I reinstated my Warlock (6-4), it seems there was none.

> I tried adding the Outlands variant map here:
> 
> http://groups.yahoo.com/group/TC_Boardgamer/files/titan_outlands.jpg

Is this just the same outer rim than ExtTitan, minus the additional
tower ? (terrains are different, I'm talking about the counter-clockwise
path).

> but ran into strange problems because the logic we use to determine
> which hexes should be inverted (and which need to be shifted down a
> half-row, but I think the two can be safely tied together) seems to
> break for a 19x10 board.  (All the hexes were upside-down.)  I tried 
> making the board 20x10 instead of 19x10, with an empty first column, to
> flip the polarity of all hexes, but that didn't work either. 
> Surprising, because ExtTitan has a 20x10 map.  So there's probably a 
> glitch in my map file.  MasterBoard.isHexInverted() probably needs to
> return different results based on the board size (I haven't figured out
> the exact function yet, but it'll be simple), to make it easier to 
> create valid maps without wasting columns or rows to align hexes.

IIRC, the board upon which ExtTitan was build is cheating, with an empty
row or colmun. You must keep the proper parity to have the proper Hex.
The adding-a-row trick should have worked. Please commit it, so I can
check if there's anything else I forgot to document in FileFormat.txt.

BTW, I believe ExTitan isn't even 20x10, I only forgot to put the "real"
size (as long as the value are >= what's needed it works, it just wastes
memory :-( )

-- 
DOLBEAU Romain               | We'll know for the first time
ENS Cachan / Ker Lann        |     If we're evil or divine
Thesard IRISA / CAPS         |          -- Dio,
dol...@cl...    |             'The Last In Line'

Hello,

I've moved all the image loading code to
"net/sf/colossus/util/ImageLoader.java",
and fixed the various place that loaded images.
the subdirectory String "images" wasmoved to
Constants, and pathSeparator now belong in
ImageLoader (needed to build the directories
List).

That makes the code much cleaner, and we may
support multiple file type (beyond .gif) by simply
adding them to ImageLoader (the caller doesn't specify
the extension, only the name and the directories
to search).

-- 
DOLBEAU Romain               |  Energy derives from both                
ENS Cachan / Ker Lann        |    the plus and negative                 
Thesard IRISA / CAPS         |       -- Metallica,                      
dol...@cl...    |           'Eye of the Beholder'

David Ripton wrote:

> This logic is already there; it's just a matter of substituting the
> image display call for the drawing code.  I would split the existing
> images into sixths and use one GIF per terrain feature hexside (e.g.
> Wall0.gif for the wall that faces north) rather than trying to paint
> sectors of the existing images on the fly.

There's commented out code in GUIBattleHex that do just that :
for each getOppositeHexside(), it draws the proper sector of
the GIF. It works, but it's not very nice. Maybe disabling
the other hexside (hard-coded) would make it looks nicer.

-- 
DOLBEAU Romain               |                                          
ENS Cachan / Ker Lann        | l'histoire est entierement vraie, puisque
Thesard IRISA / CAPS         |     je l'ai imaginee d'un bout a l'autre 
dol...@cl...    |           -- Boris Vian

Romain Dolbeau wrote:

> I've added overlay display in the Battlelands.
> I've only done the interior, not the hexside,
> as I'm unsure how to properly do that (yet).

It's a bit of a pain because the hexside art extends into the neighbor 
hexes.  So the neighbor hexes need to also know about hexside features 
which are stored in the adjacent hex, or else proper display relies on 
the order in which hexes are painted.  So it's necessary to draw based 
on both getHexside() and getOppositeHexside().

This logic is already there; it's just a matter of substituting the 
image display call for the drawing code.  I would split the existing 
images into sixths and use one GIF per terrain feature hexside (e.g. 
Wall0.gif for the wall that faces north) rather than trying to paint 
sectors of the existing images on the fly.

> I've tried to give credit to the artists in README.txt,
> but I don't know who to credit for the masterboard
> overlays. David, if you know, please fill in the blank.

Done.

-- 
David Ripton   dr...@wi...

Romain Dolbeau wrote:
>>If overlays look good on all platforms, and do not cause performance 
>>problems even on slow computers, then we can make them mandatory and 
>>delete some code

> I don't think this is a good idea. First, overlays look good on Scale 14
> or 15 and above, but they're too small below ; a shrinked bitmap is not
> as easily readable as text. Second, making them mandatory would force
> variants authors to create overlays for all terrains. And if we keep the
> fall-back text code, the only code deleted is the 'bool' gestion code,
> one item in a menu and a couple one-line functions...
> 
> I suggest making them the default display if scale is 14 or more, but
> keeping them "optional".

You're right; the code to print terrain names instead of overlays needs 
to stay.

Making this option depend on scale probably adds more work than it's 
worth, since then you have to think about what to do when scale changes. 
  I think defaulting it to on, and letting people turn it off via menu 
option or cfg file, is good enough.  (I also want to default 
autoPickRecruiters to on.)

-- 
David Ripton   dr...@wi...

Hello,

I've added overlay display in the Battlelands.
I've only done the interior, not the hexside,
as I'm unsure how to properly do that (yet).

Overlay come from the Titan Battleland Construction Kit
<http://www.angelfire.com/pq/Urhixidur/Titan/Battlelands.html>
Hence copy of this mail to the author of the page,
to ensure we _can_ reuse his graphics (please !).

I've tried to give credit to the artists in README.txt,
but I don't know who to credit for the masterboard
overlays. David, if you know, please fill in the blank.

-- 
DOLBEAU Romain               | For a hill, men would kill,              
ENS Cachan / Ker Lann        |   Why ? They do not know.                
Thesard IRISA / CAPS         |      -- Metallica,                       
dol...@cl...    |       'For Whom The Bell Tolls'

> If overlays look good on all platforms, and do not cause performance 
> problems even on slow computers, then we can make them mandatory and 
> delete some code.

I don't think this is a good idea. First, overlays look good on Scale 14
or 15 and above, but they're too small below ; a shrinked bitmap is not
as easily readable as text. Second, making them mandatory would force
variants authors to create overlays for all terrains. And if we keep the
fall-back text code, the only code deleted is the 'bool' gestion code,
one item in a menu and a couple one-line functions...

I suggest making them the default display if scale is 14 or more, but
keeping them "optional".

-- 
DOLBEAU Romain               | Brothers of Metal will always be there
ENS Cachan / Ker Lann        | Standing together with hands in the air
Thesard IRISA / CAPS         |           -- Manowar,
dol...@cl...    |                     'Brothers of Metal'

I made the MasterHex labels smaller and repositioned them a bit so they 
don't clash with the overlays.  Looks pretty good on the one machine I 
tried, but this needs testing on multiple platforms since font sizing is 
rarely perfect.

If overlays look good on all platforms, and do not cause performance 
problems even on slow computers, then we can make them mandatory and 
delete some code.

-- 
David Ripton   dr...@wi...

Romain Dolbeau wrote:

>>Did you remember to check these images into CVS as binary files?

> I did a 'cvs admin -kb' afterward ; checking them out on my main
> tree worked (Solaris 7).

CVS uses Unix text file conventions natively, and only munges files when 
importing/exporting to other OS types.  So if you forget to mark a file 
as binary, it still usually works on Unix boxes, but breaks on Windows 
boxes.  (If a binary file contains a sequence of bytes that look like 
"$Id:$" then it will get corrupted regardless of platform, of course.)

> No, i don't think we need to bump up the requirements,
> converting to transparent GIF should work.
Agreed.

-- 
David Ripton   dr...@wi...

David Ripton wrote:

> JDK 1.2 does not support PNG files, so we need to either convert the PNG
> files to GIFs, or bump the Colossus JDK version requirement to 1.3.  Any
> one have thoughts on this issue?

I've moved the PNGs to GIFs, and it still work, it seems...

-- 
DOLBEAU Romain           | I witness a time and a place that never dies,
ENS Cachan / Ker Lann    | still frozen in time, this darkness the only 
Thesard IRISA / CAPS     | place that I can hide. I witness, a dream.   
dol...@cl...|  -- Black Sabbath, 'I Witness'

David Ripton wrote:

> Are the Tundra images supposed to be blank?

Well, there's the name 'Tundra' ;-)

> Did you remember to check these images into CVS as binary files?

I did a 'cvs admin -kb' afterward ; checking them out on my main
tree worked (Solaris 7).

> JDK 1.2 does not support PNG files, so we need to either convert the PNG
> files to GIFs, or bump the Colossus JDK version requirement to 1.3.  Any
> one have thoughts on this issue?

Arg ! I could have sworn I was using 1.2.2, but I'm testing
with 1.3.1 :-(

No, i don't think we need to bump up the requirements,
converting to transparent GIF should work.

-- 
DOLBEAU Romain               | Who'd believe we'd spend more            
ENS Cachan / Ker Lann        | Shippin' drugs and guns                  
Thesard IRISA / CAPS         | Than to educate our sons?                
dol...@cl...    |   -- Megadeth, 'Youthanasia'

Romain Dolbeau wrote:

> I've added an option to display graphical overlay
> instead of names on the MasterBoard. Overlay are
> PNG files taken from
> <http://chris.howeville.com/Colossus.jar>

I remember those.  :->  Thanks for integrating them.

> I liked the graphical display, but unfortunately
> the author didn't apparently submit a patch :-(

Chris did a neat small board prototype where each hex was its own 
Component, which unfortunately didn't scale.  Then he started working on 
merging David Lum's very attractive masterboard into Colossus, but he 
ran out of time to work on it.

> In my code, the transparent display (if available
> and the option is enabled) is simply overlaid
> over the background color, instead of the name/label
> combinations.

Are the Tundra images supposed to be blank?

Did you remember to check these images into CVS as binary files?  I'm 
still having problems with the ExtTitan images even after cvs admin -kb 
-- perhaps they need to be deleted and re-added.  (Doesn't much matter, 
because Jerry is working on prettier versions.  I'm just confused as to 
why CVS isn't working as expected.)

JDK 1.2 does not support PNG files, so we need to either convert the PNG 
files to GIFs, or bump the Colossus JDK version requirement to 1.3.  Any 
one have thoughts on this issue?

-- 
David Ripton   dr...@wi...

Hello,

I've added an option to display graphical overlay
instead of names on the MasterBoard. Overlay are
PNG files taken from
<http://chris.howeville.com/Colossus.jar>
I liked the graphical display, but unfortunately
the author didn't apparently submit a patch :-(

In my code, the transparent display (if available
and the option is enabled) is simply overlaid
over the background color, instead of the name/label
combinations.

-- 
DOLBEAU Romain               | We'll know for the first time            
ENS Cachan / Ker Lann        |     If we're evil or divine              
Thesard IRISA / CAPS         |          -- Dio,                         
dol...@cl...    |             'The Last In Line'

Some of the GIFs in both the images and ExtTitan/images were not marked 
as binary in CVS.  This caused them to get corrupted when downloaded via 
CVS to a Windows box.  I just did a cvs admin -kb *.gif in both 
directories, which should fix the problem permanently with regard to 
these files.  We need to remember to do this for any future images or 
other binaries that we check into CVS.

-- 
David Ripton   dr...@wi...

dean gaudet wrote:
> On Mon, 21 Jan 2002, David Ripton wrote:
>  
>>I'm thinking about getting rid of the carry cursors completely, and
>>using a simple dialog (like PickStrikePenalty) instead of just clicking
>>on hexes to handle carries.  The current interface is a bit confusing,
>>and it's easy to accidentally lose a carry by misclicking.  A dialog
>>would be more straightforward, if a bit more fiddly.
>>
> 
> a "did you mean to throw away the carry? yes/no" dialogue for misclick
> would be rad.  in general i find the dialogues a pain though because they
> come up in places not near my mouse cursor (i know, that's a window
> manager issue).

I mostly try to pop up dialogs centered, but WMs don't always allow 
applications to control dialog positioning.  I agree that excessive 
dialog use is annoying, but so is implicitly using the same interface in 
two different modes.  Which is why changing the cursor to denote carries 
versus strikes is key.  But I'm having some strange problems with custom 
carry cursors (they work perfectly on 3 out of 5 computers, 
intermittently on #4, and not at all on #5).
> similarly a "are you sure you wish to skip mustering in the highlighted
> stacks?  yes/no" would be helpful for when you hit 'd' a little too early
> :)

That's been requested before.  I haven't put it in because I 
intentionally skip a recruit a lot more often than I forget to recruit, 
so IMO the cure would be worse than the disease.  (I could make each nag 
dialog optional, but that's a lot of baggage.)

> btw, does Colossus do anything specifically to cause a beep when
> displaying dialogues?  i've been trying to track down why i'm getting
> beeps in dialogues on redhat 7.2 with jre1.3.1_02... i don't get any beeps
> in win2k.

No, it's not intentional.  IMO it's a JDK bug.  I just thought of a 
possible workaround, which I'll try to put in tonight.

>>I'm tempted to change autoForcedStrike's behavior to also take
>>rangestrikes / carries when there's only one target.  This would reduce
>>time spent fidding with the carry dialog, since it would only show up
>>for 2+ carry targets.  Anyone have a strong objection to this?
 > i'm pretty enamoured of autoForcedStrike, but it would become useless to
 > me (and poorly named) if it included such unforced events :)
 >
 > could you do these as autoRangeSingleTarget and autoCarrySingleTarget?

Okay.

-- 
David Ripton   dr...@wi...

On Mon, 21 Jan 2002, David Ripton wrote:

> I'm thinking about getting rid of the carry cursors completely, and
> using a simple dialog (like PickStrikePenalty) instead of just clicking
> on hexes to handle carries.  The current interface is a bit confusing,
> and it's easy to accidentally lose a carry by misclicking.  A dialog
> would be more straightforward, if a bit more fiddly.

a "did you mean to throw away the carry? yes/no" dialogue for misclick
would be rad.  in general i find the dialogues a pain though because they
come up in places not near my mouse cursor (i know, that's a window
manager issue).

similarly a "are you sure you wish to skip mustering in the highlighted
stacks?  yes/no" would be helpful for when you hit 'd' a little too early
:)

btw, does Colossus do anything specifically to cause a beep when
displaying dialogues?  i've been trying to track down why i'm getting
beeps in dialogues on redhat 7.2 with jre1.3.1_02... i don't get any beeps
in win2k.

> I'm tempted to change autoForcedStrike's behavior to also take
> rangestrikes / carries when there's only one target.  This would reduce
> time spent fidding with the carry dialog, since it would only show up
> for 2+ carry targets.  Anyone have a strong objection to this?

i frequently choose not to rangestrike or carry in cases where i don't
want an enemy to die on that attack -- for example, i might have my titan
up front in a position that would be exceedingly weak if one of the enemy
does die... in these cases i'll throw away carries or rangestrikes.  or i
might have a 7 stack and not want to kill an enemy until the enemy can
kill one of mine, so that i can summon an angel.

i'm pretty enamoured of autoForcedStrike, but it would become useless to
me (and poorly named) if it included such unforced events :)

could you do these as autoRangeSingleTarget and autoCarrySingleTarget?

laters
-dean

Just added files for the simple TitanPlus variant from the Titan 
rulebook.  They're in the TitanPlus subdirectory.

The unused tower creatures are included in the .cre file because 
SimpleAI refers to them explicitly by name.  SimpleAI's hardcoded 
initial split and mulligan logic need to be generalized a bit to play 
variants well.  I'd rather not start adding variant-specific AI 
subclasses for a while, though -- I'm still making radical changes to 
the Client/Server interface, and it's enough of a pain to have to keep 
one AI in sync, let alone more.

There are some problems with unsetting carry cursors, repaints after 
carries and AI recruits, etc. right now.  I should be able to fix them 
tonight.


I'm thinking about getting rid of the carry cursors completely, and 
using a simple dialog (like PickStrikePenalty) instead of just clicking 
on hexes to handle carries.  The current interface is a bit confusing, 
and it's easy to accidentally lose a carry by misclicking.  A dialog 
would be more straightforward, if a bit more fiddly.

I'm tempted to change autoForcedStrike's behavior to also take 
rangestrikes / carries when there's only one target.  This would reduce 
time spent fidding with the carry dialog, since it would only show up 
for 2+ carry targets.  Anyone have a strong objection to this? 
autoForcedStrike is of course optional, for purists who want to preserve 
the option to to less damage than they could since that comes in handy 
once in a while, and those who just enjoy clicking a lot.

-- 
David Ripton   dr...@wi...

David Ripton wrote:

> Some of the new creature images appear to be truncated, and some of the
> old creature images show the wrong power.  I'm going to see if Jerry
> Reiger, the guy who did a bunch of the other images for Colossus, would
> be willing to clean up the ExtTitan images for us.

Yes, I didn't update the old images, and the new are ugly
(it's only scaled-down verison of those on the web).
BTW, replacing images by the same name used not to wrok,
but I fixed that over the week-end.

-- 
DOLBEAU Romain           | I witness a time and a place that never dies,
ENS Cachan / Ker Lann    | still frozen in time, this darkness the only 
Thesard IRISA / CAPS     | place that I can hide. I witness, a dream.   
dol...@cl...|  -- Black Sabbath, 'I Witness'

Romain Dolbeau wrote:


> I moved all the knowledge on BattleHex to BattleHex.java,
> where it belongs ; BattleHex can now report the known
> Terrains and HexSides ; this is used by BattlelandsBuilder
> to create the popup-menu. BattleHex can also report
> the HexSide as String now.


Excellent.


> I changed the Water Dweller a bit in more_native ;
> they are now 'amphibious' creatures (the old way was
> unplayable), that take damage when in Sand (in addition
> to Drift, handled the same way).
> 
> I'll wait for agreement on that before merging more_native.


Fine with me.

BTW, I finally tried Extended Titan.  That's a huge map with some 
seriously counterintuitive movement.  All that space makes for a much 
more recruiting-oriented game.  Not sure if it would be fun against 
other humans or if it would just take forever, but it's neat against the AI.

Some of the new creature images appear to be truncated, and some of the 
old creature images show the wrong power.  I'm going to see if Jerry 
Reiger, the guy who did a bunch of the other images for Colossus, would 
be willing to clean up the ExtTitan images for us.

-- 
David Ripton   dr...@wi...

Hi,

I moved all the knowledge on BattleHex to BattleHex.java,
where it belongs ; BattleHex can now report the known
Terrains and HexSides ; this is used by BattlelandsBuilder
to create the popup-menu. BattleHex can also report
the HexSide as String now.

I changed the Water Dweller a bit in more_native ;
they are now 'amphibious' creatures (the old way was
unplayable), that take damage when in Sand (in addition
to Drift, handled the same way).

I'll wait for agreement on that before merging more_native.

-- 
DOLBEAU Romain            | For a hill, men would kill, Why ?          
ENS Cachan / Ker Lann     | They do not know.                          
Thesard IRISA / CAPS      | -- Metallica in 'For Whom The Bell Tolls'  
dol...@cl... |