colossus-tracker Mailing List for Colossus (Page 55)

Feature Requests item #674122, was opened at 2003-01-24 18:47
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351939&aid=674122&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Ben Bishop (benbishop)
Assigned to: Nobody/Anonymous (nobody)
Summary: Network Game Startup

Initial Comment:
When starting the server instance for a netwoek game 
there is no clue that anything is going on.

A small window detailing the game participants and 
whether they have connected yet (or need to) would 
make starting up a network game much less confusing.

Once the game started, of course, there would no longer 
be a need for that window.

The window should also have a cancel button in case its 
decided to cancel the game (otherwise the server just 
sits around forever, no?).

Ben

----------------------------------------------------------------------

>Comment By: Clemens Katzer (cleka)
Date: 2007-09-14 23:53

Message:
Logged In: YES 
user_id=1717697
Originator: NO


Server side part of this was implemented 10.3.2007
(in revision 2619), so it has been part of the public
build since 17.4.2007.

Client side is nothing yet, though... 

If you give wrong server, it will hang in a timeout;
but if you give wrong port, or start client to early
(i.e. before the server player has started the game),
client will immeidately die with a socket exception.

So, yes, there's lot of room for improvement... :-/

-Clemens



----------------------------------------------------------------------

Comment By: Mike Weber (San Diego) (mdweber_jamul)
Date: 2005-01-01 23:38

Message:
Logged In: YES 
user_id=1188413

Absolutely - something like:
a) Waiting for 2 network client(s)....
then
b) Client 1 (123.45.67.89 {or computer alias} has connected.
Waiting for 1 network client(s)...
then
c) All network clients connected, starting game...

Also, from the network client side, there should be indications 
that 
a) Looking for host game
b) Found host game
along with a timeout if the host game cannot be found.

Mike


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351939&aid=674122&group_id=1939

Feature Requests item #936736, was opened at 2004-04-17 05:31
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351939&aid=936736&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: Ben Bishop (benbishop)
Assigned to: Nobody/Anonymous (nobody)
Summary: Option documentation?

Initial Comment:
There seems to be no documentation on what some of 
the game options mean. 

What does "Slowing is cumulative" mean?

What does "Always allow one hex" mean?

and lastly, what does "use non-random battle dice" 
actually imply?  Does it /force/ average dice?

What do the AI Delay and Current AI time limits actually 
control?


----------------------------------------------------------------------

>Comment By: Clemens Katzer (cleka)
Date: 2007-09-14 23:32

Message:
Logged In: YES 
user_id=1717697
Originator: NO


Option documentation is now on Colossus home page
(on the "full docs are _here_ page, 
  http://colossus.sourceforge.net/docs/index.html

The links to server side and client side options 
are also available from inside Colossus under Help 
menu (not clickable, have to copy paste, but anyway...)

So, I think this here can be closed.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351939&aid=936736&group_id=1939

Bugs item #1758248, was opened at 2007-07-22 00:49
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1758248&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GUI
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 2
Private: No
Submitted By: Clemens Katzer (cleka)
Assigned to: Clemens Katzer (cleka)
Summary: Help - About does not work when auto play is on

Initial Comment:

When Autoplay => auto play is selected, 
the window that should come when selecting 
Help => About does not appear.

If one switches auto play off, it works again.
Tried it in 2 variants (Beelzebub12 and Abyssal6),
result is the same.

Java 1.4.2_12 on Windows XP.


----------------------------------------------------------------------

>Comment By: Clemens Katzer (cleka)
Date: 2007-09-11 22:29

Message:
Logged In: YES 
user_id=1717697
Originator: YES


About - info box is now shown no matter whether
Autoplay is active or not. => Closed.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1758248&group_id=1939

Bugs item #839662, was opened at 2003-11-11 02:34
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=839662&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: AI
Group: None
>Status: Pending
Resolution: Fixed
Priority: 3
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Corwin Joy (corwinjoy)
Summary: titans stop splitting etc

Initial Comment:
with both rational AI and human hater AI the enemy 
titans stop splitting before they even get behemoths. 
They almost all go for the jungle but dont understand 
when is smart to split. Its almost as if u can put a  
stack within maybe (5 or 6)  hexes of the titan,,and its 
afraid to split, even in the tower sometimes.

----------------------------------------------------------------------

>Comment By: Clemens Katzer (cleka)
Date: 2007-09-11 09:45

Message:
Logged In: YES 
user_id=1717697
Originator: NO


I propose to close this bug. At least MilvangAI and 
SimpleAI manage to get Serpents - Rational did not in 
my tests, but I did not run too many games to find out.

The original topic of this - "does not split" - I would say
is solved with Corwins corrections, and that the AIs
in general need improvement ... well I guess we do not
need a reminder for that :)

I set this to Pending, and if noone objects SF-robot will 
close this after some weeks.

-Clemens



----------------------------------------------------------------------

Comment By: Corwin Joy (corwinjoy)
Date: 2004-02-15 01:48

Message:
Logged In: YES 
user_id=126654

There are actually two bugs in here.
1) The default terrain recruiting logic is broken so that the AIs 
always go for Gorgons instead of a third cyclops.  I reported 
this a while back but have upped the priority and sent in on 
to David.
2) The HumanHaterRational AI's had a bug that caused stacks 
to never split.  I have fixed this so that they are now splitting.
3) I have changed the AI logic to get it not make more 5/2 
splits and not consider a 4/2 unless it thinks the legion 
is "safe"

Beyond this, I agree with milvang the general problem of 
getting the AIs of knowing when to split is simply hard.  We 
have some logic, but it's still not very smart.

----------------------------------------------------------------------

Comment By: Kim Milvang-Jensen (milvang)
Date: 2004-02-11 16:23

Message:
Logged In: YES 
user_id=972236

It is hard to clasify this as a bug.

The AIs are for now pretty simple, and making them 
competible is going to take a lot of work. I plan to work on 
making a better AI myself.

My personal experience with the AI, is actually to opposite 
problem, spitting the titan too often and getting killed while 
still a 5 or a 6 stack.

While splitting the right way is no all the hard, splitting at the 
right times is the hardest part of playing Titan, and any 
thoughts on good splitting algorithms is appreciated.

----------------------------------------------------------------------

Comment By: Bret Thorson (slohanz)
Date: 2003-11-21 02:00

Message:
Logged In: YES 
user_id=906257

I had a game yesterday with no stacks anywhere this titan 
with 2 1st level creatures still in it..and it wouldn't split.

The AI titan is willing to risk death attacking another titan 
yet in most cases NEVER splits once it fills up the 1st time.

The AI also needs to make more 5/2 splits. The 3/4s are risky 
the way it does it..and the 3/3's are just no help to them at 
all.

A stack with 2 grif, 2 minis and 3 rangers split  off the 2 minis 
by themselves..hey that's just too easy to kill off:)

In all of these cases I'm speaking of games vs 4-5 rational or 
human hater AI's but in many of the games the theme is 
similar. The AI makes many bad splits (or badly placed/timed 
splits) with all of its stacks but the titan while the titan just 
stays weak the whole game from never making a split after 
turn 1.

I dont know a thing about these programs but If the AI can 
be made to strategize better,,it would own:)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=839662&group_id=1939

Bugs item #1753815, was opened at 2007-07-14 01:17
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1753815&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Clemens Katzer (cleka)
Summary: Creature shown at possible stack dest is not always best

Initial Comment:
In the game whose save-file is attached, it is my movement phase, and I've rolled a 5.  The legion in plains 129 can move to plains 124 and muster a ranger, but when I click on the legion, the program displays a lion in 124, not a ranger.

I'm assuming it is supposed to show the player the best possible recruit in each space.

----------------------------------------------------------------------

>Comment By: Clemens Katzer (cleka)
Date: 2007-09-11 09:15

Message:
Logged In: YES 
user_id=1717697
Originator: NO


After newest public build original submitter confirmed
this to be fixed. => Setting it to Closed.

----------------------------------------------------------------------

Comment By: Clemens Katzer (cleka)
Date: 2007-07-26 00:11

Message:
Logged In: YES 
user_id=1717697
Originator: NO


Now there is a public build done, which has the new
choices for "recruit preview" and also the docs on 
the web site have now the updated contents.
"Help" => "Options Documentation" tells the links,
so you don't need to search them somewhere else to
copy-paste them...


I guess now the things are clearer? Then this bug here
could be closed...

-Clemens



----------------------------------------------------------------------

Comment By: Clemens Katzer (cleka)
Date: 2007-07-14 09:40

Message:
Logged In: YES 
user_id=1717697
Originator: NO


*grmpf* ;-)

That's because I changed the "what does it show" from "strongest"
to "what would auto recruit take", i.e. the Recruit hint.
And in 124 the recruit hint suggests you a lion so that in 
the next desert (which is in reach) you could get a griffon.


Someone else submitted that same problem:
 
http://sourceforge.net/tracker/index.php?func=detail&aid=1745850&group_id=1939&atid=101939
but because I committed a solution to that I closed it already.
Should have waited until next public build, as I did with some other
bugs:-(


The solution to above situation is, now it's your choice what
the recruit preview will show you on destination land;
the "show all recruits"is changed to a 4-way-choice 
"Recruit preview shows" [None, Strongest, Recruit Hint, All].

And the best is, I have now finally made a document describing all 
the client side options, including the above! :)



----------------------------------------------------------------------

Comment By: John David Galt (jdgalt)
Date: 2007-07-14 03:03

Message:
Logged In: YES 
user_id=624416
Originator: NO

I submitted this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1753815&group_id=1939

Bugs item #1769985, was opened at 2007-08-08 14:49
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1769985&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ben Bishop (benbishop)
Assigned to: Nobody/Anonymous (nobody)
Summary: Auto quit when game over never changes

Initial Comment:
I inadvertantly chose "Auto quit when game over" in options.  Loading a saved game, however, seems to overwrite the option settings, at which point there is no way to switch back to it not auto quitting.

Note that I didn't find the 'auto quit' option in the save file, but in the user profile; so it seems that if you change auto quit it doesn't immediately save the change to the profile.

----------------------------------------------------------------------

>Comment By: Clemens Katzer (cleka)
Date: 2007-09-10 23:44

Message:
Logged In: YES 
user_id=1717697
Originator: NO


Interesting side effect... should now be fixed,
but it might take a while to next public build :-/


----------------------------------------------------------------------

Comment By: Ben Bishop (benbishop)
Date: 2007-09-10 21:49

Message:
Logged In: YES 
user_id=14669
Originator: YES

Since this was added to the new public buiold, the list of player (and
player types) on the start screen now default to 'none' rather than the
prior values.  It appears that information is not getting saved as part of
the configuration.

----------------------------------------------------------------------

Comment By: Ben Bishop (benbishop)
Date: 2007-09-10 21:49

Message:
Logged In: YES 
user_id=14669
Originator: YES

Since this was added to the new public buiold, the list of player (and
player types) on the start screen now default to 'none' rather than the
prior values.  It appears that information is not getting saved as part of
the configuration.

----------------------------------------------------------------------

Comment By: Clemens Katzer (cleka)
Date: 2007-08-14 23:51

Message:
Logged In: YES 
user_id=1717697
Originator: NO


Fixed with revision 2709.

GetPlayers dialog saves server side options now back to
cfg file when one loads a game (not only when starting 
a new game).


----------------------------------------------------------------------

Comment By: Clemens Katzer (cleka)
Date: 2007-08-10 00:12

Message:
Logged In: YES 
user_id=1717697
Originator: NO


Yes, there is something fishy here, but you as user could
see only half of the truth :)

What actually happened here is:
"When one _loads_ a game from GetPlayers menu, the changed options
are in effect for the starting/loaded game, but they are not stored back 
to settings file, and thus, when one comes next time to that dialog 
(which initializes itself from the file), they are back to what they were
before".

A little bit more detailed explanation, for those who are
interested.... :


Changes to server side settings ( = the options in the 
GetPlayers dialog before starting the game) are stored to
the settings file only when one presses "New Game"; but not 
when one presses "Load Game" ( = that is the actual bug here).


Have you tried whether it actually quits when game over when
the "did not take the change" happened ? Because it would not 
do so, I believe.

I made some tests where I print the value of Auto quit to
the screen when the actual game starts; what happens is, 
that when you e.g. change auto quit to false and then press 
load game, the auto quit false is indeed in effect for that 
game, but since it was not stored to the server cfg file, then
when you try next time "New Game" (e.g. from File menu) there it
is back to true again.

So, to resolve your problem, you have to change it, press once
"New Game" ( this write changes back), 
and when you after that next time come to the GetPlayers dialog 
where you can set the options, it's state has changed.


BTW; when you press QUIT on that dialog it does not save any
changed options either.

And basically this behavior should be likewise for all other
settings in that dialog, only in others it's more easy to notice
what is the "actually in effect value" of that setting.
(yes, I just tried it - for view mode and expire option happens
 just the same).

BTW2, the value of "Auto quit when game over" in user profile
( = "Colossus-<playername>.cf") is totally bogus - there is nothing
in client side that reads this setting. The actual place where
this value is stored is the Colossus-server.cfg file.
(why it is transferred then to the client, and that one saves it?
 Don't know ... just by accident, I guess... *shrug* ;-)

Could be cleaned as well, when one is up to fix this here...


Still, the behavior you describe is a bug - it's not reasonable
that the changed options do not take effect when one presses Load,
but one can have them effect by first New Game and then restart
and press Load.


-Clemens



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1769985&group_id=1939

Bugs item #1769985, was opened at 2007-08-08 07:49
Message generated for change (Comment added) made by benbishop
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1769985&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ben Bishop (benbishop)
Assigned to: Nobody/Anonymous (nobody)
Summary: Auto quit when game over never changes

Initial Comment:
I inadvertantly chose "Auto quit when game over" in options.  Loading a saved game, however, seems to overwrite the option settings, at which point there is no way to switch back to it not auto quitting.

Note that I didn't find the 'auto quit' option in the save file, but in the user profile; so it seems that if you change auto quit it doesn't immediately save the change to the profile.

----------------------------------------------------------------------

>Comment By: Ben Bishop (benbishop)
Date: 2007-09-10 14:49

Message:
Logged In: YES 
user_id=14669
Originator: YES

Since this was added to the new public buiold, the list of player (and
player types) on the start screen now default to 'none' rather than the
prior values.  It appears that information is not getting saved as part of
the configuration.

----------------------------------------------------------------------

Comment By: Ben Bishop (benbishop)
Date: 2007-09-10 14:49

Message:
Logged In: YES 
user_id=14669
Originator: YES

Since this was added to the new public buiold, the list of player (and
player types) on the start screen now default to 'none' rather than the
prior values.  It appears that information is not getting saved as part of
the configuration.

----------------------------------------------------------------------

Comment By: Clemens Katzer (cleka)
Date: 2007-08-14 16:51

Message:
Logged In: YES 
user_id=1717697
Originator: NO


Fixed with revision 2709.

GetPlayers dialog saves server side options now back to
cfg file when one loads a game (not only when starting 
a new game).


----------------------------------------------------------------------

Comment By: Clemens Katzer (cleka)
Date: 2007-08-09 17:12

Message:
Logged In: YES 
user_id=1717697
Originator: NO


Yes, there is something fishy here, but you as user could
see only half of the truth :)

What actually happened here is:
"When one _loads_ a game from GetPlayers menu, the changed options
are in effect for the starting/loaded game, but they are not stored back 
to settings file, and thus, when one comes next time to that dialog 
(which initializes itself from the file), they are back to what they were
before".

A little bit more detailed explanation, for those who are
interested.... :


Changes to server side settings ( = the options in the 
GetPlayers dialog before starting the game) are stored to
the settings file only when one presses "New Game"; but not 
when one presses "Load Game" ( = that is the actual bug here).


Have you tried whether it actually quits when game over when
the "did not take the change" happened ? Because it would not 
do so, I believe.

I made some tests where I print the value of Auto quit to
the screen when the actual game starts; what happens is, 
that when you e.g. change auto quit to false and then press 
load game, the auto quit false is indeed in effect for that 
game, but since it was not stored to the server cfg file, then
when you try next time "New Game" (e.g. from File menu) there it
is back to true again.

So, to resolve your problem, you have to change it, press once
"New Game" ( this write changes back), 
and when you after that next time come to the GetPlayers dialog 
where you can set the options, it's state has changed.


BTW; when you press QUIT on that dialog it does not save any
changed options either.

And basically this behavior should be likewise for all other
settings in that dialog, only in others it's more easy to notice
what is the "actually in effect value" of that setting.
(yes, I just tried it - for view mode and expire option happens
 just the same).

BTW2, the value of "Auto quit when game over" in user profile
( = "Colossus-<playername>.cf") is totally bogus - there is nothing
in client side that reads this setting. The actual place where
this value is stored is the Colossus-server.cfg file.
(why it is transferred then to the client, and that one saves it?
 Don't know ... just by accident, I guess... *shrug* ;-)

Could be cleaned as well, when one is up to fix this here...


Still, the behavior you describe is a bug - it's not reasonable
that the changed options do not take effect when one presses Load,
but one can have them effect by first New Game and then restart
and press Load.


-Clemens



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1769985&group_id=1939

Bugs item #1769985, was opened at 2007-08-08 07:49
Message generated for change (Comment added) made by benbishop
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1769985&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ben Bishop (benbishop)
Assigned to: Nobody/Anonymous (nobody)
Summary: Auto quit when game over never changes

Initial Comment:
I inadvertantly chose "Auto quit when game over" in options.  Loading a saved game, however, seems to overwrite the option settings, at which point there is no way to switch back to it not auto quitting.

Note that I didn't find the 'auto quit' option in the save file, but in the user profile; so it seems that if you change auto quit it doesn't immediately save the change to the profile.

----------------------------------------------------------------------

>Comment By: Ben Bishop (benbishop)
Date: 2007-09-10 14:49

Message:
Logged In: YES 
user_id=14669
Originator: YES

Since this was added to the new public buiold, the list of player (and
player types) on the start screen now default to 'none' rather than the
prior values.  It appears that information is not getting saved as part of
the configuration.

----------------------------------------------------------------------

Comment By: Clemens Katzer (cleka)
Date: 2007-08-14 16:51

Message:
Logged In: YES 
user_id=1717697
Originator: NO


Fixed with revision 2709.

GetPlayers dialog saves server side options now back to
cfg file when one loads a game (not only when starting 
a new game).


----------------------------------------------------------------------

Comment By: Clemens Katzer (cleka)
Date: 2007-08-09 17:12

Message:
Logged In: YES 
user_id=1717697
Originator: NO


Yes, there is something fishy here, but you as user could
see only half of the truth :)

What actually happened here is:
"When one _loads_ a game from GetPlayers menu, the changed options
are in effect for the starting/loaded game, but they are not stored back 
to settings file, and thus, when one comes next time to that dialog 
(which initializes itself from the file), they are back to what they were
before".

A little bit more detailed explanation, for those who are
interested.... :


Changes to server side settings ( = the options in the 
GetPlayers dialog before starting the game) are stored to
the settings file only when one presses "New Game"; but not 
when one presses "Load Game" ( = that is the actual bug here).


Have you tried whether it actually quits when game over when
the "did not take the change" happened ? Because it would not 
do so, I believe.

I made some tests where I print the value of Auto quit to
the screen when the actual game starts; what happens is, 
that when you e.g. change auto quit to false and then press 
load game, the auto quit false is indeed in effect for that 
game, but since it was not stored to the server cfg file, then
when you try next time "New Game" (e.g. from File menu) there it
is back to true again.

So, to resolve your problem, you have to change it, press once
"New Game" ( this write changes back), 
and when you after that next time come to the GetPlayers dialog 
where you can set the options, it's state has changed.


BTW; when you press QUIT on that dialog it does not save any
changed options either.

And basically this behavior should be likewise for all other
settings in that dialog, only in others it's more easy to notice
what is the "actually in effect value" of that setting.
(yes, I just tried it - for view mode and expire option happens
 just the same).

BTW2, the value of "Auto quit when game over" in user profile
( = "Colossus-<playername>.cf") is totally bogus - there is nothing
in client side that reads this setting. The actual place where
this value is stored is the Colossus-server.cfg file.
(why it is transferred then to the client, and that one saves it?
 Don't know ... just by accident, I guess... *shrug* ;-)

Could be cleaned as well, when one is up to fix this here...


Still, the behavior you describe is a bug - it's not reasonable
that the changed options do not take effect when one presses Load,
but one can have them effect by first New Game and then restart
and press Load.


-Clemens



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1769985&group_id=1939

Bugs item #1789116, was opened at 2007-09-06 06:28
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1789116&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Clemens Katzer (cleka)
>Summary: illegal move: 29 plain to 2000 tundra

Initial Comment:
during my recent 2 games, legions at 29 plain cannot move to 2000 tundra when rolling a 4
it keeps saying "illegal move"


----------------------------------------------------------------------

>Comment By: Clemens Katzer (cleka)
Date: 2007-09-06 10:34

Message:
Logged In: YES 
user_id=1717697
Originator: NO


Same thing has been reported before:
  1737239  	  Illegal Move

http://sourceforge.net/tracker/index.php?func=detail&aid=1737239&group_id=1939&atid=101939

Seems this is not reproducable, depends on the users PC, 
java version, or other things. So please report all those things:
- Your operating system, 
- Java version (e.g. in Colossus Help => About), 
- which variant, 
- how many human/AI/network players (local only, or remote server),
- do you have "Auto pick entry side" option active (Autoplay menu),
- does it happen every time when you try this move or only occasionally?
  (or course once it happens in one game, from then on always,
   but in another, new game (totally QUIT the whole application
between!!),
   would it happen on first attempt immediately again?)

TIP: You can reproduce the plain 29 situation very easily - before game
start,
set in the startup menu the "unlimited mulligans", then when needed press
"M"
until you get the roll that let's you go to the plain 29 and next time
as long until you get a four to go to tundra.


The only way we can fix this, if a person on whose PC this happens.
is willing to help on this - send in logfile, run a specialized version
which prints more debug output (e.g. in the part of code which decides
whether it is a illegal move or not, make it tell more concrete 
"which fact makes it illegal" and such.

I have now made improvements on this "illegal move" message so that 
it tells a concrete reason (wrong entry side, target hex not in list
of hexes etc.), i.e. why does the server consider this illegal.

If David does a new build soon, one would get some more clue what
is the issue here - in general.

But from then on, we would need to refine it - make it print more detailed

info in this parts of code which are involved, and we can't always make a

new public build to get more debugging output ...
So, if I would build such a special version for you, and send you a jar or

zip file (1-2 MB), are you willing to run it (e.g. from commandline) ?

If you are not willing to reveal your name/email here, could you email
me directly -- my name (cleka) and then the at and then
users.sourceforge.net ?


Regards, 
-Clemens



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1789116&group_id=1939

Bugs item #1789116, was opened at 2007-09-05 20:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1789116&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: David Ripton (dripton)
Summary: 29 plain to 2000 tundra

Initial Comment:
during my recent 2 games, legions at 29 plain cannot move to 2000 tundra when rolling a 4
it keeps saying "illegal move"


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1789116&group_id=1939

Bugs item #1782181, was opened at 2007-08-26 19:13
Message generated for change (Comment added) made by dripton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1782181&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Java
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: David Ripton (dripton)
Summary: Does not start with JRE 1.5

Initial Comment:
Problem:  The game won't start.
O/S: Linux (Fedora Core 5)
Java Version: J2SE JRE 1.5.0
Game Version: Vanilla 20070724 build
Email address: neo...@ya...

Raw error output:

Exception in thread "main" java.lang.NoSuchMethodError: method javax.swing.text.html.HTMLEditorKit.getStyleSheet with signature ()Ljavax.swing.text.html.StyleSheet; was not found.
   at net.sf.colossus.util.ResourceLoader.getDocument (ResourceLoader.java:714)
   at net.sf.colossus.server.VariantSupport.loadVariant (VariantSupport.java:197)
   at net.sf.colossus.server.VariantSupport.loadVariant (VariantSupport.java:87)
   at net.sf.colossus.client.ShowReadme.readmeContentScrollPane (ShowReadme.java:89)
   at net.sf.colossus.server.GetPlayers.<init> (GetPlayers.java:220)
   at net.sf.colossus.server.Start.startupDialog (Start.java:95)
   at net.sf.colossus.server.Start.main (Start.java:328)

To replicate the problem:

1) unziped the zip file to an empty subdirectory
2) edited the 'unix.jnlp' "codebase" tag to point to the directory the game was unzipped to
3) make the 'run' script executable (i.e. "chmod 755 run")
4) Start the game (i.e. "./run" or "java -jar Colossus.jar")

----------------------------------------------------------------------

>Comment By: David Ripton (dripton)
Date: 2007-09-02 13:24

Message:
Logged In: YES 
user_id=9425
Originator: NO

Colossus works for me, on Linux, with Java 1.4 and 1.5 and 1.6.

Closing since you got it working.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-09-01 02:59

Message:
Logged In: NO 

My apologies.  It turns out that when I upgraded from Java 1.4.2 (which
comes standard with a vanilla Fedora 5) to Java 1.5.0 via RPMs, the old
version is not upgraded.  My problem was *actually* related to 1.4.2 not
working correctly.  I fixed that error on my system and can now verify that
Colossus works with java 1.5.0

In that vein, it appears that something in
"javax.swing.text.html.HTMLEditorKit.getStyleSheet" got changed or renamed
between v1.4.2 and v1.5.0.  After some *very casual* crawling through the
Colossus code and my limited knowledge of Java, I don't believe there's
much you can do to fix the problem.

----------------------------------------------------------------------

Comment By: David Ripton (dripton)
Date: 2007-08-27 08:08

Message:
Logged In: YES 
user_id=9425
Originator: NO

You should not need to touch the jnlp file -- that's just for Java Web
Start.

Looks like your Java Runtime Environment can't find some builtin
libraries.

Does the game start okay if you click on the Colossus icon on the web page
to run it through Java Web Start?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1782181&group_id=1939

Bugs item #1782181, was opened at 2007-08-26 16:13
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1782181&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Java
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: David Ripton (dripton)
Summary: Does not start with JRE 1.5

Initial Comment:
Problem:  The game won't start.
O/S: Linux (Fedora Core 5)
Java Version: J2SE JRE 1.5.0
Game Version: Vanilla 20070724 build
Email address: neo...@ya...

Raw error output:

Exception in thread "main" java.lang.NoSuchMethodError: method javax.swing.text.html.HTMLEditorKit.getStyleSheet with signature ()Ljavax.swing.text.html.StyleSheet; was not found.
   at net.sf.colossus.util.ResourceLoader.getDocument (ResourceLoader.java:714)
   at net.sf.colossus.server.VariantSupport.loadVariant (VariantSupport.java:197)
   at net.sf.colossus.server.VariantSupport.loadVariant (VariantSupport.java:87)
   at net.sf.colossus.client.ShowReadme.readmeContentScrollPane (ShowReadme.java:89)
   at net.sf.colossus.server.GetPlayers.<init> (GetPlayers.java:220)
   at net.sf.colossus.server.Start.startupDialog (Start.java:95)
   at net.sf.colossus.server.Start.main (Start.java:328)

To replicate the problem:

1) unziped the zip file to an empty subdirectory
2) edited the 'unix.jnlp' "codebase" tag to point to the directory the game was unzipped to
3) make the 'run' script executable (i.e. "chmod 755 run")
4) Start the game (i.e. "./run" or "java -jar Colossus.jar")

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-08-31 23:59

Message:
Logged In: NO 

My apologies.  It turns out that when I upgraded from Java 1.4.2 (which
comes standard with a vanilla Fedora 5) to Java 1.5.0 via RPMs, the old
version is not upgraded.  My problem was *actually* related to 1.4.2 not
working correctly.  I fixed that error on my system and can now verify that
Colossus works with java 1.5.0

In that vein, it appears that something in
"javax.swing.text.html.HTMLEditorKit.getStyleSheet" got changed or renamed
between v1.4.2 and v1.5.0.  After some *very casual* crawling through the
Colossus code and my limited knowledge of Java, I don't believe there's
much you can do to fix the problem.

----------------------------------------------------------------------

Comment By: David Ripton (dripton)
Date: 2007-08-27 05:08

Message:
Logged In: YES 
user_id=9425
Originator: NO

You should not need to touch the jnlp file -- that's just for Java Web
Start.

Looks like your Java Runtime Environment can't find some builtin
libraries.

Does the game start okay if you click on the Colossus icon on the web page
to run it through Java Web Start?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1782181&group_id=1939

Bugs item #1782181, was opened at 2007-08-26 19:13
Message generated for change (Comment added) made by dripton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1782181&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Java
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: David Ripton (dripton)
Summary: Does not start with JRE 1.5

Initial Comment:
Problem:  The game won't start.
O/S: Linux (Fedora Core 5)
Java Version: J2SE JRE 1.5.0
Game Version: Vanilla 20070724 build
Email address: neo...@ya...

Raw error output:

Exception in thread "main" java.lang.NoSuchMethodError: method javax.swing.text.html.HTMLEditorKit.getStyleSheet with signature ()Ljavax.swing.text.html.StyleSheet; was not found.
   at net.sf.colossus.util.ResourceLoader.getDocument (ResourceLoader.java:714)
   at net.sf.colossus.server.VariantSupport.loadVariant (VariantSupport.java:197)
   at net.sf.colossus.server.VariantSupport.loadVariant (VariantSupport.java:87)
   at net.sf.colossus.client.ShowReadme.readmeContentScrollPane (ShowReadme.java:89)
   at net.sf.colossus.server.GetPlayers.<init> (GetPlayers.java:220)
   at net.sf.colossus.server.Start.startupDialog (Start.java:95)
   at net.sf.colossus.server.Start.main (Start.java:328)

To replicate the problem:

1) unziped the zip file to an empty subdirectory
2) edited the 'unix.jnlp' "codebase" tag to point to the directory the game was unzipped to
3) make the 'run' script executable (i.e. "chmod 755 run")
4) Start the game (i.e. "./run" or "java -jar Colossus.jar")

----------------------------------------------------------------------

>Comment By: David Ripton (dripton)
Date: 2007-08-27 08:08

Message:
Logged In: YES 
user_id=9425
Originator: NO

You should not need to touch the jnlp file -- that's just for Java Web
Start.

Looks like your Java Runtime Environment can't find some builtin
libraries.

Does the game start okay if you click on the Colossus icon on the web page
to run it through Java Web Start?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1782181&group_id=1939

Bugs item #1782181, was opened at 2007-08-26 16:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1782181&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Java
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: David Ripton (dripton)
Summary: Does not start with JRE 1.5

Initial Comment:
Problem:  The game won't start.
O/S: Linux (Fedora Core 5)
Java Version: J2SE JRE 1.5.0
Game Version: Vanilla 20070724 build
Email address: neo...@ya...

Raw error output:

Exception in thread "main" java.lang.NoSuchMethodError: method javax.swing.text.html.HTMLEditorKit.getStyleSheet with signature ()Ljavax.swing.text.html.StyleSheet; was not found.
   at net.sf.colossus.util.ResourceLoader.getDocument (ResourceLoader.java:714)
   at net.sf.colossus.server.VariantSupport.loadVariant (VariantSupport.java:197)
   at net.sf.colossus.server.VariantSupport.loadVariant (VariantSupport.java:87)
   at net.sf.colossus.client.ShowReadme.readmeContentScrollPane (ShowReadme.java:89)
   at net.sf.colossus.server.GetPlayers.<init> (GetPlayers.java:220)
   at net.sf.colossus.server.Start.startupDialog (Start.java:95)
   at net.sf.colossus.server.Start.main (Start.java:328)

To replicate the problem:

1) unziped the zip file to an empty subdirectory
2) edited the 'unix.jnlp' "codebase" tag to point to the directory the game was unzipped to
3) make the 'run' script executable (i.e. "chmod 755 run")
4) Start the game (i.e. "./run" or "java -jar Colossus.jar")

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1782181&group_id=1939

Bugs item #1769985, was opened at 2007-08-08 14:49
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1769985&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ben Bishop (benbishop)
Assigned to: Nobody/Anonymous (nobody)
Summary: Auto quit when game over never changes

Initial Comment:
I inadvertantly chose "Auto quit when game over" in options.  Loading a saved game, however, seems to overwrite the option settings, at which point there is no way to switch back to it not auto quitting.

Note that I didn't find the 'auto quit' option in the save file, but in the user profile; so it seems that if you change auto quit it doesn't immediately save the change to the profile.

----------------------------------------------------------------------

>Comment By: Clemens Katzer (cleka)
Date: 2007-08-14 23:51

Message:
Logged In: YES 
user_id=1717697
Originator: NO


Fixed with revision 2709.

GetPlayers dialog saves server side options now back to
cfg file when one loads a game (not only when starting 
a new game).


----------------------------------------------------------------------

Comment By: Clemens Katzer (cleka)
Date: 2007-08-10 00:12

Message:
Logged In: YES 
user_id=1717697
Originator: NO


Yes, there is something fishy here, but you as user could
see only half of the truth :)

What actually happened here is:
"When one _loads_ a game from GetPlayers menu, the changed options
are in effect for the starting/loaded game, but they are not stored back 
to settings file, and thus, when one comes next time to that dialog 
(which initializes itself from the file), they are back to what they were
before".

A little bit more detailed explanation, for those who are
interested.... :


Changes to server side settings ( = the options in the 
GetPlayers dialog before starting the game) are stored to
the settings file only when one presses "New Game"; but not 
when one presses "Load Game" ( = that is the actual bug here).


Have you tried whether it actually quits when game over when
the "did not take the change" happened ? Because it would not 
do so, I believe.

I made some tests where I print the value of Auto quit to
the screen when the actual game starts; what happens is, 
that when you e.g. change auto quit to false and then press 
load game, the auto quit false is indeed in effect for that 
game, but since it was not stored to the server cfg file, then
when you try next time "New Game" (e.g. from File menu) there it
is back to true again.

So, to resolve your problem, you have to change it, press once
"New Game" ( this write changes back), 
and when you after that next time come to the GetPlayers dialog 
where you can set the options, it's state has changed.


BTW; when you press QUIT on that dialog it does not save any
changed options either.

And basically this behavior should be likewise for all other
settings in that dialog, only in others it's more easy to notice
what is the "actually in effect value" of that setting.
(yes, I just tried it - for view mode and expire option happens
 just the same).

BTW2, the value of "Auto quit when game over" in user profile
( = "Colossus-<playername>.cf") is totally bogus - there is nothing
in client side that reads this setting. The actual place where
this value is stored is the Colossus-server.cfg file.
(why it is transferred then to the client, and that one saves it?
 Don't know ... just by accident, I guess... *shrug* ;-)

Could be cleaned as well, when one is up to fix this here...


Still, the behavior you describe is a bug - it's not reasonable
that the changed options do not take effect when one presses Load,
but one can have them effect by first New Game and then restart
and press Load.


-Clemens



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1769985&group_id=1939

Bugs item #1769985, was opened at 2007-08-08 14:49
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1769985&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: General
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ben Bishop (benbishop)
Assigned to: Nobody/Anonymous (nobody)
Summary: Auto quit when game over never changes

Initial Comment:
I inadvertantly chose "Auto quit when game over" in options.  Loading a saved game, however, seems to overwrite the option settings, at which point there is no way to switch back to it not auto quitting.

Note that I didn't find the 'auto quit' option in the save file, but in the user profile; so it seems that if you change auto quit it doesn't immediately save the change to the profile.

----------------------------------------------------------------------

>Comment By: Clemens Katzer (cleka)
Date: 2007-08-10 00:12

Message:
Logged In: YES 
user_id=1717697
Originator: NO


Yes, there is something fishy here, but you as user could
see only half of the truth :)

What actually happened here is:
"When one _loads_ a game from GetPlayers menu, the changed options
are in effect for the starting/loaded game, but they are not stored back 
to settings file, and thus, when one comes next time to that dialog 
(which initializes itself from the file), they are back to what they were
before".

A little bit more detailed explanation, for those who are
interested.... :


Changes to server side settings ( = the options in the 
GetPlayers dialog before starting the game) are stored to
the settings file only when one presses "New Game"; but not 
when one presses "Load Game" ( = that is the actual bug here).


Have you tried whether it actually quits when game over when
the "did not take the change" happened ? Because it would not 
do so, I believe.

I made some tests where I print the value of Auto quit to
the screen when the actual game starts; what happens is, 
that when you e.g. change auto quit to false and then press 
load game, the auto quit false is indeed in effect for that 
game, but since it was not stored to the server cfg file, then
when you try next time "New Game" (e.g. from File menu) there it
is back to true again.

So, to resolve your problem, you have to change it, press once
"New Game" ( this write changes back), 
and when you after that next time come to the GetPlayers dialog 
where you can set the options, it's state has changed.


BTW; when you press QUIT on that dialog it does not save any
changed options either.

And basically this behavior should be likewise for all other
settings in that dialog, only in others it's more easy to notice
what is the "actually in effect value" of that setting.
(yes, I just tried it - for view mode and expire option happens
 just the same).

BTW2, the value of "Auto quit when game over" in user profile
( = "Colossus-<playername>.cf") is totally bogus - there is nothing
in client side that reads this setting. The actual place where
this value is stored is the Colossus-server.cfg file.
(why it is transferred then to the client, and that one saves it?
 Don't know ... just by accident, I guess... *shrug* ;-)

Could be cleaned as well, when one is up to fix this here...


Still, the behavior you describe is a bug - it's not reasonable
that the changed options do not take effect when one presses Load,
but one can have them effect by first New Game and then restart
and press Load.


-Clemens



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1769985&group_id=1939

Bugs item #1769985, was opened at 2007-08-08 07:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1769985&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ben Bishop (benbishop)
Assigned to: Nobody/Anonymous (nobody)
Summary: Auto quit when game over never changes

Initial Comment:
I inadvertantly chose "Auto quit when game over" in options.  Loading a saved game, however, seems to overwrite the option settings, at which point there is no way to switch back to it not auto quitting.

Note that I didn't find the 'auto quit' option in the save file, but in the user profile; so it seems that if you change auto quit it doesn't immediately save the change to the profile.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1769985&group_id=1939

Feature Requests item #685169, was opened at 2003-02-12 00:00
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351939&aid=685169&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: Craig Lish (clish)
Assigned to: Nobody/Anonymous (nobody)
Summary: Remember 'Graphics' menu settings

Initial Comment:
Excellent job on persistance, on everything really! 
Something that I keep doing (cuz I play it alot!) is going 
to 'Graphics' and selecting the 'Status Screen' and then 
resizing it (so it fits next to the board in my 1280x1024 4-
player game). Would be nice if it remembered this stuff 
at some point :oP

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2007-08-06 19:20

Message:
Logged In: YES 
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Clemens Katzer (cleka)
Date: 2007-07-23 14:27

Message:
Logged In: YES 
user_id=1717697
Originator: NO


Nowadays there are 6 satellite windows:

- game status
- inspector
- engagement results
- event viewer
- caretakers stack
- full recruit tree (slightly different usage, one calls it up on request
with F,
    so it does not stay open across sessions)

And they all remember their size and position - in a new game they are
restored exactly as they were when quitting previous one.
(of course, if you would be tidy and close all satellite windows before
quit,
 they are closed when starting again! ;-)

-- so, I assume we can consider this one here as solved?

I set this to pending, thus if noone objects it will be 
closed by the system after some while (4 weeks or what?).


[NOTE: with the upcoming public build they are moved to "Window"
       submenu instead of Graphics submenu).


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2003-02-16 14:26

Message:
Logged In: NO 

I've never had a problem with this - all of my settings are 
remembered.  With one of the recent releases, the file 
Colossus pulled its configurations from change 
from "Colossus" to ".colossus" under "Documents
and 
Settings\<User Name>".  You might see if you have that 
directory on your computer and create it if it's missing.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351939&aid=685169&group_id=1939

Bugs item #1733311, was opened at 2007-06-08 12:09
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1733311&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General
Group: None
>Status: Closed
Resolution: None
Priority: 3
Private: No
Submitted By: Clemens Katzer (cleka)
Assigned to: Clemens Katzer (cleka)
Summary: Concede shown as fled

Initial Comment:

When a legion concedes, this is shown in Engagement
result window and EventViewer as "fled" instead of
conceded.


----------------------------------------------------------------------

>Comment By: Clemens Katzer (cleka)
Date: 2007-07-28 19:17

Message:
Logged In: YES 
user_id=1717697
Originator: YES


Public build done which brings that fix, so this can be closed.


----------------------------------------------------------------------

Comment By: Clemens Katzer (cleka)
Date: 2007-06-09 23:03

Message:
Logged In: YES 
user_id=1717697
Originator: YES

Fixed in r2695.
So this can be closed some point, e.g. after next public build.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1733311&group_id=1939

Feature Requests item #1725644, was opened at 2007-05-25 17:28
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351939&aid=1725644&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: replacing a human

Initial Comment:
Hello,

This may already be possible, but I don't think so.  I would like to be able replace a human with an AI player.  Many times when we save a game, some of the humans won't want to continue if they are doing poorly or maybe just can't play the next session.

Thanks,
Bill
waw...@ho...

----------------------------------------------------------------------

>Comment By: Clemens Katzer (cleka)
Date: 2007-07-28 14:32

Message:
Logged In: YES 
user_id=1717697
Originator: NO


It's not directly visible as feature but there are at least 2 things you
can do:

1) if you just want *any* AI to continue player (don't care which), I
would suggest
you put the player to autoplay, then a SimpleAI will play for him; you
will just have
an additional window (or 2 in a battle), but if they are minimized they
should not disturb too much…

To do so, one human player starts a 2nd network client, connects in place
of that 
missing player, sets it from the "Autoplay" (formerly "Player") menu to
"autoplay"; 
do then one split phase and press the "Done" button.
Now the AI should kick in and continue playing, and you can minimize that
window.


2) save the game e.g. as "mygame", and edit the .xml file manually to
replace the type.
The xml files are usually under   $HOME/.colossus/saves/ 
e.g. in WinXP that would be for me as user "katzer" here:

C:\Documents and Settings\katzer\.colossus\saves\

What is your "HOME directory" Colossus tells you under Help => About
as "user.home".

Find the mygame.xml file, open it for editing with notepad or some other
text editor 
(e.g. open notepad, and drag & drop the filename onto it).


Search for the line with the Player, e.g. search for "type="  :

<Player name="katzer" type="net.sf.colossus.client.Human" color="Green"
startingTower="400" score="0" dead="false" mulligansLeft="1" colorsElim=""
movementRoll="1" teleported="false" summoned="false">
        <Legion name="Gr03" currentHex="116" startingHex="116"
moved="false" entrySide="1" parent="null" recruitName="null"
battleTally="0">


Replace the type "Human" with one of e.g. SimpleAI, RationalAI,
MilvangAI.

<Player name="katzer" type="net.sf.colossus.client.MilvangAI"
color="Green" startingTower="400" score="0" dead="false" mulligansLeft="1"
colorsElim="" movementRoll="1" teleported="false" summoned="false">
        <Legion name="Gr03" currentHex="116" startingHex="116"
moved="false" entrySide="1" parent="null" recruitName="null"
battleTally="0">


If the game now is loaded again, this will be an AI player and it will NOT
have an own board as in solution 1).




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351939&aid=1725644&group_id=1939

Bugs item #619718, was opened at 2002-10-07 07:28
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=619718&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General
Group: None
>Status: Closed
Resolution: Accepted
Priority: 8
Private: No
Submitted By: Ben Bishop (benbishop)
Assigned to: David Ripton (dripton)
Summary: rangestrike in woods by a Centaur?

Initial Comment:
Running 20021004, 'Default' game.

Encounter in Woods, Troll + 3 Ogres defending vs AI 
legion with Centaurs and Warbear

Troll enters and stands behind a tree, Ogres move on 
elsewhere.

AI moves on, positions Centaur on opposite side of tree; 
next thing I know, the Troll has 1 point of damage -- *no* 
rangestrikers, no ground hazard (like Drifts).  Only 
plausible scenario would be if Centaurs are allowed 
to "kick" through trees as a "rangestrike".

I didn't have debug logs or even game logs on to capture 
info on the event.

Ben Bishop

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2007-07-27 19:20

Message:
Logged In: YES 
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Clemens Katzer (cleka)
Date: 2007-07-13 04:07

Message:
Logged In: YES 
user_id=1717697
Originator: NO


Has anyone still encountered similar problems after that?
I did never see this happen.

Otherwise I would suppose the cause was simply the 
"server client out of sync" issue and the problem vanished
when that was fixed.

Since that sounds most likely to me I propose to put this 
one here to Closed.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-11-25 15:46

Message:
Logged In: NO 

Just a guess (I haven't tried digging into the code), but could it be that
the client-server positions getting out of sync 
caused one of them to think the creatures were adjacent, and therefore
initiated a strikeback by the lion, and then 
the code responsible for doing the strike saw the correct positions and
concluded "the pieces aren't adjacent, so 
this must be a rangestrike".  That seems like it could result in a
rangestrike by a lion during strikeback. -- 
do...@ic...

----------------------------------------------------------------------

Comment By: David Ripton (dripton)
Date: 2002-11-21 12:36

Message:
Logged In: YES 
user_id=9425

But the rangestriking lion is still a bug.

----------------------------------------------------------------------

Comment By: David Ripton (dripton)
Date: 2002-11-21 07:09

Message:
Logged In: YES 
user_id=9425

Fixed the bug that let client/server ideas of creature
position get out of sync after a failed creature move.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-11-14 04:08

Message:
Logged In: NO 

I forgot to mention that my lion-rangestrikes-a-cyc bug arose (a) using
20021026, and (b) in solo (non-networked) 
play, default rules.   -- do...@ic...

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-11-14 03:11

Message:
Logged In: NO 

I just saw what must be the same bug.  I had a Cyc in Brush, hiding in
brambles to try for a time victory where the 
attacker was down to just a lion.  The lion didn't close, but suddenly my
Cyc took another 2 damage!  I scuttled 
over to the java output window and saw:

Lion in A1 strikes Cyclops in Brambles hex E3 with strike number 5 : 56: 2
hits

Not only that, but it was during his strikeback on my defender round 7. 
So a non-rangestriking creature (lion) took 
a rangestrike, for longer range than should have been possible, at a time
when not eligible to take rangestrikes.  
What the heck is going on? -- do...@ic...


----------------------------------------------------------------------

Comment By: David Ripton (dripton)
Date: 2002-10-08 10:01

Message:
Logged In: YES 
user_id=9425

No, centaurs can't attack through trees.  (There's an Ent
variant that lets Ents do that, but we haven't coded it
yet.)  Sounds like the client and server have a creature's
position out of sync.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=619718&group_id=1939

Bugs item #1753815, was opened at 2007-07-14 01:17
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1753815&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Clemens Katzer (cleka)
Summary: Creature shown at possible stack dest is not always best

Initial Comment:
In the game whose save-file is attached, it is my movement phase, and I've rolled a 5.  The legion in plains 129 can move to plains 124 and muster a ranger, but when I click on the legion, the program displays a lion in 124, not a ranger.

I'm assuming it is supposed to show the player the best possible recruit in each space.

----------------------------------------------------------------------

>Comment By: Clemens Katzer (cleka)
Date: 2007-07-26 00:11

Message:
Logged In: YES 
user_id=1717697
Originator: NO


Now there is a public build done, which has the new
choices for "recruit preview" and also the docs on 
the web site have now the updated contents.
"Help" => "Options Documentation" tells the links,
so you don't need to search them somewhere else to
copy-paste them...


I guess now the things are clearer? Then this bug here
could be closed...

-Clemens



----------------------------------------------------------------------

Comment By: Clemens Katzer (cleka)
Date: 2007-07-14 09:40

Message:
Logged In: YES 
user_id=1717697
Originator: NO


*grmpf* ;-)

That's because I changed the "what does it show" from "strongest"
to "what would auto recruit take", i.e. the Recruit hint.
And in 124 the recruit hint suggests you a lion so that in 
the next desert (which is in reach) you could get a griffon.


Someone else submitted that same problem:
 
http://sourceforge.net/tracker/index.php?func=detail&aid=1745850&group_id=1939&atid=101939
but because I committed a solution to that I closed it already.
Should have waited until next public build, as I did with some other
bugs:-(


The solution to above situation is, now it's your choice what
the recruit preview will show you on destination land;
the "show all recruits"is changed to a 4-way-choice 
"Recruit preview shows" [None, Strongest, Recruit Hint, All].

And the best is, I have now finally made a document describing all 
the client side options, including the above! :)



----------------------------------------------------------------------

Comment By: John David Galt (jdgalt)
Date: 2007-07-14 03:03

Message:
Logged In: YES 
user_id=624416
Originator: NO

I submitted this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1753815&group_id=1939

Bugs item #1734908, was opened at 2007-06-11 03:46
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1734908&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: AI
Group: None
Status: Open
Resolution: None
Priority: 3
Private: No
Submitted By: Clemens Katzer (cleka)
Assigned to: David Ripton (dripton)
Summary: AI does not make room to let reenforcement enter

Initial Comment:

Defending CowardAI in the desert. Did reinforce a lion.

Lion could have come in, if the AI would have moved
the guardian out of the way (guardian was not engaged).

Still Lion was displayed as did not enter battle field.

The attachment zip file contains a JPEG showing
the situation and the logfile.
No autosave file, unfortunately :-(



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-07-25 09:26

Message:
Logged In: NO 

CowardAI consistantly fails to move pieces to allow reenforcement enter if
entry spaces are blocked on reenforcement turn.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1734908&group_id=1939

Feature Requests item #700479, was opened at 2003-03-09 12:26
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351939&aid=700479&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: David desJardins (daviddesj)
Assigned to: Nobody/Anonymous (nobody)
Summary: too easy to end phase

Initial Comment:
By far my biggest problem with Colossus is that it's
too easy to accidentally end a phase.  I think this has
happened to me at least once in every game I've played.
 I would much much much prefer a button to click on to
end the phase, and disabling the 'd' key.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-07-24 05:56

Message:
Logged In: NO 


> Does the new version let you disable the "d" key?

No. I thought you refer to pressing D it could bounce,
and hence asked for the button.

hmm... and someone else, ATOH,  would even like to 
have different keys for different phases.

Perhaps we should make the keys customizable :)

-Cle.


----------------------------------------------------------------------

Comment By: David desJardins (daviddesj)
Date: 2007-07-23 14:29

Message:
Logged In: YES 
user_id=718698
Originator: YES

Does the new version let you disable the "d" key?  I will try it.  Just
adding a different way to end the turn doesn't solve the problem, as it's
still easy to accidentally type "d" (e.g., when intending to send a chat
message).

----------------------------------------------------------------------

Comment By: Clemens Katzer (cleka)
Date: 2007-07-23 14:13

Message:
Logged In: YES 
user_id=1717697
Originator: NO


David (dJ),

now that there is the button and menu bar item to end the phase,
can we consider this here as "solved" ?


----------------------------------------------------------------------

Comment By: Dranathi (dranathi)
Date: 2007-03-05 05:45

Message:
Logged In: YES 
user_id=1735321
Originator: NO

Would adding an option to toggle the display of a "phase done"
confirmation dialog also be helpful?

----------------------------------------------------------------------

Comment By: David Ripton (dripton)
Date: 2003-03-10 07:49

Message:
Logged In: YES 
user_id=9425

Adding an option to disable hotkeys is trivial, though
without a toolbar probably too painful to be useful.

Adding a toolbar is pretty easy.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351939&aid=700479&group_id=1939

Feature Requests item #700479, was opened at 2003-03-09 12:26
Message generated for change (Comment added) made by daviddesj
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351939&aid=700479&group_id=1939

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: David desJardins (daviddesj)
Assigned to: Nobody/Anonymous (nobody)
Summary: too easy to end phase

Initial Comment:
By far my biggest problem with Colossus is that it's
too easy to accidentally end a phase.  I think this has
happened to me at least once in every game I've played.
 I would much much much prefer a button to click on to
end the phase, and disabling the 'd' key.


----------------------------------------------------------------------

>Comment By: David desJardins (daviddesj)
Date: 2007-07-23 14:29

Message:
Logged In: YES 
user_id=718698
Originator: YES

Does the new version let you disable the "d" key?  I will try it.  Just
adding a different way to end the turn doesn't solve the problem, as it's
still easy to accidentally type "d" (e.g., when intending to send a chat
message).

----------------------------------------------------------------------

Comment By: Clemens Katzer (cleka)
Date: 2007-07-23 14:13

Message:
Logged In: YES 
user_id=1717697
Originator: NO


David (dJ),

now that there is the button and menu bar item to end the phase,
can we consider this here as "solved" ?


----------------------------------------------------------------------

Comment By: Dranathi (dranathi)
Date: 2007-03-05 05:45

Message:
Logged In: YES 
user_id=1735321
Originator: NO

Would adding an option to toggle the display of a "phase done"
confirmation dialog also be helpful?

----------------------------------------------------------------------

Comment By: David Ripton (dripton)
Date: 2003-03-10 07:49

Message:
Logged In: YES 
user_id=9425

Adding an option to disable hotkeys is trivial, though
without a toolbar probably too painful to be useful.

Adding a toolbar is pretty easy.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351939&aid=700479&group_id=1939