colossus-tracker Mailing List for Colossus (Page 44)

Bugs item #2073991, was opened at 2008-08-25 20:27
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=2073991&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: Clemens Katzer (cleka)
Summary: Game hangs on AI Split

Initial Comment:
Build 20080822 under XP
java version 1.5.0_08

In Abyssal9, got around to 'sky' and the game hangs on Sky Turn 18 "split stacks"

Attached is the save file. (or will be if I can trim it down to <250k...)

So, can't trim it (too many data files in it and no indication on what might be "optional")

you can download the save from:
http://www.pileofstuff.com/sky_hang.xml

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

>Comment By: Clemens Katzer (cleka)
Date: 2008-08-25 22:42

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


I downloaded and tried the sky_hang file. But as reported in another
report,
it seems loading a game has went broken recently (can't even load one I
saved myself).
((So this needs fixing first ))-:

Anyway, while loading yours, there is first plenty of errors, but then
repeatedly:

WARNING: Sky got nak for doSplit Illegal split
SEVERE: split failed for Sk05
WARNING: Sky got nak for doSplit Illegal split
SEVERE: split failed for Sk05
WARNING: Sky got nak for doSplit Illegal split
SEVERE: split failed for Sk05
WARNING: Sky got nak for doSplit Illegal split
SEVERE: split failed for Sk05
WARNING: Sky got nak for doSplit Illegal split
SEVERE: split failed for Sk05
WARNING: Sky got nak for doSplit Illegal split
SEVERE: split failed for Sk05
WARNING: Sky got nak for doSplit Illegal split
SEVERE: split failed for Sk05
WARNING: Sky got nak for doSplit Illegal split
SEVERE: split failed for Sk05
WARNING: Sky got nak for doSplit Illegal split
SEVERE: split failed for Sk05
WARNING: Sky got nak for doSplit Illegal split
...
endlessly, I'd guess, I aborted it some point.

So, I guess that's why it hangs - AI tries to do some split and server
rejects it again and again.

(Hm. I thought I fixed this type of error already once ;-)

I'll take a look at it, anyway...

-CleKa

PS: 

I didn't manage to attach a file either - web page rejected 
it first (too big, too),
and when I compressed it some other error message:

"File Upload: ArtifactFile: Could not open file for writing"

... together with a green "ok" symbol ;-)


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

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

Bugs item #2074220, was opened at 2008-08-25 22:32
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=2074220&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: 6
Private: No
Submitted By: Clemens Katzer (cleka)
Assigned to: Clemens Katzer (cleka)
Summary: Exception while loading game with dead players

Initial Comment:


When loading a game (in which some players are already dead) game gets an exception:

D:\workspace\Trunk1>java -Djava.util.logging.config.file=logging.properties -Xmx128M -jar Colossus.jar --load Round34.xml

WARNING: Can't find legion for markerId 'Br04'
SEVERE: Exception while waiting on selector
java.lang.NullPointerException
        at net.sf.colossus.server.History.fireEventFromElement(History.java:368)
        at net.sf.colossus.server.History.fireEventsFromXML(History.java:211)
        at net.sf.colossus.server.GameServerSide.loadGame2(GameServerSide.java:1818)
        at net.sf.colossus.server.Server.startGameIfAllPlayers(Server.java:792)
        at net.sf.colossus.server.ClientHandler.callMethod(ClientHandler.java:209)
        at net.sf.colossus.server.ClientHandler.processInput(ClientHandler.java:137)
        at net.sf.colossus.server.Server.waitOnSelector(Server.java:292)
        at net.sf.colossus.server.Server.run(Server.java:145)

Startup progress window is still up and says "ok, got all clients, game can start now" (and probably it would do so, but during doing so it dies with the exception).

When one closes the window then with Abort button, plenty of error messages are printed to the console, and after that one is back to the main game setup (Player Selection) dialog.



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

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

Bugs item #2073991, was opened at 2008-08-25 13:27
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=2073991&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: Game hangs on AI Split

Initial Comment:
Build 20080822 under XP
java version 1.5.0_08

In Abyssal9, got around to 'sky' and the game hangs on Sky Turn 18 "split stacks"

Attached is the save file. (or will be if I can trim it down to <250k...)

So, can't trim it (too many data files in it and no indication on what might be "optional")

you can download the save from:
http://www.pileofstuff.com/sky_hang.xml

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

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

Bugs item #2072769, was opened at 2008-08-25 05:50
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=2072769&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: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Clemens Katzer (cleka)
Summary: Game hangs when AI titan killed by AI

Initial Comment:
I'd killed an AI titan already and the game didn't hang. When an AI (non-titan group) killed an AI titan the game hung on the dead titan's strikeback phase. Both were Rational AI. Playing Abyssal6.

c_...@ya...

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

>Comment By: Clemens Katzer (cleka)
Date: 2008-08-25 09:52

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

Hi,

were you as human player still alive then?

I noticed that there is a problem in some case: when AIs fight to the end,

when the Titan is killed, the game does not update the Game status window,

so it looks like there would still be 2 or more players alive, 
and the "XXX wins" is not displayed; 
but if one looks in the log, there is (perhaps 6-8.-last message) the "xxx
wins!" log entry.

Can you verify whether this is there / confirm you were still alive,
and the last battle was NOT a Titan-vs-Titan battle?

---

I've let the game run 100+ rounds of stresstest (all players AI against
each other)
and none of them did hang... they do autoquit when "xxx wins" is reached,
but the 
message does not reach the client to be displayed there.)

BR,

Clemens


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

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

Bugs item #2072769, was opened at 2008-08-25 02:50
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=2072769&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: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: David Ripton (dripton)
Summary: Game hangs when AI titan killed by AI

Initial Comment:
I'd killed an AI titan already and the game didn't hang. When an AI (non-titan group) killed an AI titan the game hung on the dead titan's strikeback phase. Both were Rational AI. Playing Abyssal6.

c_...@ya...

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

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

Bugs item #1895129, was opened at 2008-02-17 00:20
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1895129&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: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Clemens Katzer (cleka)
>Summary: carryover gui issue: should not close with "x"

Initial Comment:
If when presented with the carryover prompt you click someplace outside of the prompt then you forgoe your carryover even if you click on a selection that requests it. This happens in current cvs, though has been going on for a long time. (When I first started suspecting this behavior, I wasn't sure that I had really clicked on the right menu item.)

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

>Comment By: Clemens Katzer (cleka)
Date: 2008-08-23 16:10

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


The normal carry (original request) all works fine, and is visible in
public build 2008-08-22.

=> Renaming this to "x" specific to make it clear that only that small
issue is missing.

-CleKa


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

Comment By: Clemens Katzer (cleka)
Date: 2008-08-22 18:45

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


Mostly solved, but one tiny issue with it still:

Implemented "can click to carry" and clicking anywhere else does not harm
in r3328.
Only closing the dialog with the "x" leaves the targets highlighted and
there's no way
out of that state except clicking one of the targets.
Didn't get the GUI make call the WindowClosing method, for some reason...

So, this bug might stay open as reminder until that issue is resolved
too...

-CleKa


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

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

Feature Requests item #558825, was opened at 2002-05-21 22:48
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351939&aid=558825&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: 4
Private: No
Submitted By: Bill Barksdale (wcbarksdale)
Assigned to: Clemens Katzer (cleka)
>Summary: Select strike penalty by clicking creature

Initial Comment:
It would be nice if you could click on the legion you would like to spill to rather than being forced to hunt for it.  The same is true for the decision to strike up.

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

>Comment By: Clemens Katzer (cleka)
Date: 2008-08-23 16:08

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


OK, the carries are implemented and visible in public build 2008-08-22.

Renaming this FR tracker item to the remaining issue about taking a strike
penalty.
Not sure whether this will be done any time soon, though...

-CleKa


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

Comment By: Clemens Katzer (cleka)
Date: 2008-08-22 17:58

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

For carries (spillover) implemented in r3328.
It's now a non-modal dialog (was already), and valid targets may be also
clicked 
on the board (additionally to the dialog); clicking anywhere else does NOT
terminate
the chance to carry excees damage (as it did before).

Just don't close the dialog with the "x" dialog, that's not good (yet;-)

For "strike up" (strike penalties??) it's not done, and it's somewhat more
complicated there.

-CleKa


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

Comment By: David Ripton (dripton)
Date: 2002-05-22 01:04

Message:
Logged In: YES 
user_id=9425

We used to do carries via clicking on hexes, but it confused
people.  The current modal dialog is ugly but straightforward.

The optimal solution would be a non-modal dialog off to the
side, along with hex highlighting.  It's a bit of work, though.

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

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

Bugs item #592044, was opened at 2002-08-07 16:10
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=592044&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: Network
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 3
Private: No
Submitted By: Klint (khull)
>Assigned to: Clemens Katzer (cleka)
Summary: Network client doesn't save connect info

Initial Comment:
The drop-down boxes available on the network client 
form don't save the name nor the host IP address 
information you enter.  The client always resets to its 
defaults: the machine's name and "localhost."  I 
wouldn't think the port would be retained, either.

It would be very useful if the client saved a list of the 
most recent entries and used the most recent as its 
default on start-up.



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

>Comment By: Clemens Katzer (cleka)
Date: 2008-08-23 16:06

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


Closing this; it's not a bug, and for the two missing ones
(name & port) I rather created an explicit Feature Request:

[ 2069658 ] Network client: LRU lists also for port+playername

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

-Cleka


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

Comment By: Clemens Katzer (cleka)
Date: 2008-08-23 15:01

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


Summary: for host it works just fine,
but for port and username perhaps could still be improved.

-CleKa

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

Comment By: Clemens Katzer (cleka)
Date: 2008-05-20 09:43

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


The network client now remembers (via saving to a cf file
"colossus-netclient.cf")
the list of last 10 used hosts; additionally current hostname and IP
address 
are always part of the list.
The list is stored in LRU order in file, but displayed alphabetically, 
and the initially selected item is the "least receantly used" one.
 ( == what this tracker item was mostly about is fulfilled).


For Name and Port, there is no list in the file; when starting
a new game within same run, username keeps its previous value
and port keeps used port in pulldown list (but is not active/selected.
  That's kind of a bug).

If one starts Colossus new, name and port are always the defaults again:
system's login name,     except if overriden with -m Option, which works
fine.
and default port 26567, "except if overriden" with -p Option. 

In the latter case, the override does not work (the port nr.
given on cmdline appears as option in the pulldown menu but
is not the selected one; I'd say this is a bug...)


---

This comment is meant just as update on the situation; 
leaving this tracker item open as reminder that there is still room for
improvement here...

-Clemens


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

Comment By: David Ripton (dripton)
Date: 2002-08-09 16:21

Message:
Logged In: YES 
user_id=9425

I added that feature a while back.  Not sure why it's not
working for you.  Maybe I broke it when changing
initialization to fix a different bug.

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

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

Feature Requests item #2069658, was opened at 2008-08-23 16:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351939&aid=2069658&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: Clemens Katzer (cleka)
Assigned to: Clemens Katzer (cleka)
Summary: Network client: LRU lists also for port+playername

Initial Comment:

Network Client should/could remember via cf file earlier used Port and Playernames as LRU list same way as it does for Hostnames/addresses.

(it preserves port and name from previous game in same started application, but not over closing the whole application and starting it (via JSW or commandline) again - then they are back to default.)

-CleKa


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

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

Bugs item #592044, was opened at 2002-08-07 16:10
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=592044&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: Network
Group: None
Status: Open
>Resolution: Remind
Priority: 3
Private: No
Submitted By: Klint (khull)
Assigned to: David Ripton (dripton)
Summary: Network client doesn't save connect info

Initial Comment:
The drop-down boxes available on the network client 
form don't save the name nor the host IP address 
information you enter.  The client always resets to its 
defaults: the machine's name and "localhost."  I 
wouldn't think the port would be retained, either.

It would be very useful if the client saved a list of the 
most recent entries and used the most recent as its 
default on start-up.



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

>Comment By: Clemens Katzer (cleka)
Date: 2008-08-23 15:01

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


Summary: for host it works just fine,
but for port and username perhaps could still be improved.

-CleKa

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

Comment By: Clemens Katzer (cleka)
Date: 2008-05-20 09:43

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


The network client now remembers (via saving to a cf file
"colossus-netclient.cf")
the list of last 10 used hosts; additionally current hostname and IP
address 
are always part of the list.
The list is stored in LRU order in file, but displayed alphabetically, 
and the initially selected item is the "least receantly used" one.
 ( == what this tracker item was mostly about is fulfilled).


For Name and Port, there is no list in the file; when starting
a new game within same run, username keeps its previous value
and port keeps used port in pulldown list (but is not active/selected.
  That's kind of a bug).

If one starts Colossus new, name and port are always the defaults again:
system's login name,     except if overriden with -m Option, which works
fine.
and default port 26567, "except if overriden" with -p Option. 

In the latter case, the override does not work (the port nr.
given on cmdline appears as option in the pulldown menu but
is not the selected one; I'd say this is a bug...)


---

This comment is meant just as update on the situation; 
leaving this tracker item open as reminder that there is still room for
improvement here...

-Clemens


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

Comment By: David Ripton (dripton)
Date: 2002-08-09 16:21

Message:
Logged In: YES 
user_id=9425

I added that feature a while back.  Not sure why it's not
working for you.  Maybe I broke it when changing
initialization to fix a different bug.

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

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

Bugs item #2069565, was opened at 2008-08-23 14:56
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=2069565&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: 2
Private: No
Submitted By: Clemens Katzer (cleka)
Assigned to: Clemens Katzer (cleka)
Summary: WARNING: Rolled rollMovementDie() more than once

Initial Comment:

When loading a game, on console is usually always printed:

WARNING: Called rollMovementDie() more than once

(This is in r3332, Java 1.5.0_07 on WinXP, but happens probably in any case).

-CleKa


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

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

Bugs item #2026169, was opened at 2008-07-24 00:48
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=2026169&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: Cannot Accept Negotiation on "Hotseat" 1 vs. 1 game

Initial Comment:
When one player offers another player a negotiation while playing hotseat style, the other player is unable to accept the deal.  When they click accept, the window disappears, but the dialogue box still appears for the first player to accept/decline the initial offer.  Attached is an image of what happens upon resending the offer.

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

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

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


Now visible in public build 2008-22-08 => closing this.


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

Comment By: Clemens Katzer (cleka)
Date: 2008-08-11 22:32

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

As I suspected, the problem is not the hotseat mode, but the fact that the

negotiation dialog didn't/doesn't work at all - not in normal mode
either.
Now that the dialog is fixed (since revision r3295, 2008-08-10), 
it's working fine also in hotseat mode.

Still, I leave this tracker item open until the next public build.


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

Comment By: Clemens Katzer (cleka)
Date: 2008-08-09 23:06

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


Oh my... I wish I had never started that Hotset thingy... 
it's far from completed (e.g. does not cover battle board at all yet) 
and naturally I did not consider special cases like this.
Perhaps I should mark it " (Experimental!)" in the startupdialog... ;-)

What's worse, I have never managed to complete a negotiation with 
Colossus on either of my two computers (both XP) - it always keeps popping

up windows, no matter what I click. 
I suspected the negotiation stuff simply does not work on XP at all and
forgot 
about it for good...

And since I cannot exercise a successful neg. dialog anyway, my chances
of
fixing this bug are rather modest :-(

Can you confirm you did earlier do successful negotiations in non-Hotseat
mode?

-Clemens


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

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

Bugs item #1965117, was opened at 2008-05-16 10:12
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1965117&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: Closing (initial) marker selection dialog: should come back

Initial Comment:

During the initial Color selection and legion marker selection:

If one closes the color selection with the "x" in right top corner, the dialog pops up again - fine.

If one closes the marker selection dialog like that -- it stays away. No way to proceed with the game, need to start a new one.



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

>Comment By: Clemens Katzer (cleka)
Date: 2008-08-23 14:48

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

Now visible in public build 2008-08-22 => Closing this.


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

Comment By: Clemens Katzer (cleka)
Date: 2008-05-16 23:12

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

Fixed with r3273.


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

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

Bugs item #1941803, was opened at 2008-04-14 10:45
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1941803&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: 3
Private: No
Submitted By: Clemens Katzer (cleka)
Assigned to: Clemens Katzer (cleka)
Summary: Color selection dialog sometimes wraps

Initial Comment:


Depending on screen resolution and scale value: In the color selection dialog, sometimes there are only 11 colors in first line, and the last (12th, usually indigo), is wrapped to next line; but this 2nd line is not visible to the user (the dialog is not high enough to show it, and there is no scrollbar).

E.g. for 1280x1024, scale 15 its wrapped, but scale 14 it's fine.

As far as I see this is a rather old issue, even already in revision 2952 from 3.1.2008, build with Java 1.4.2 , this happens.


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

>Comment By: Clemens Katzer (cleka)
Date: 2008-08-23 14:46

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


Now visible in public build 2008-08-22 => Closing this.


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

Comment By: Clemens Katzer (cleka)
Date: 2008-08-11 22:46

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

David changed this later (r3275), now Color selection dialog 
is displayed as 3x4 instead of all in one row.
(Still no public build yet even now).


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

Comment By: Clemens Katzer (cleka)
Date: 2008-05-15 21:04

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


Fixed in r3271 (not in public build yet)

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

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

Bugs item #2028230, was opened at 2008-07-25 23:51
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=2028230&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
Resolution: Fixed
Priority: 7
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Clemens Katzer (cleka)
Summary: Terrain penalties not applied in combat 

Initial Comment:
Newest trunk version via Java Web Start.


Penalties for terrain during battle are not being applied. 

Example:

An ogre in the brambles striking another ogre is needing a 4 to hit, but non-native creatures should lose a skill factor striking in or out of brambles.

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

>Comment By: Clemens Katzer (cleka)
Date: 2008-08-23 14:42

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


Visible in public build, so closing this.

Adding a TODO in client/Strike.java before getDice() reminding that 
that is duplicate code and servr side code should be reused instead.

-CleKa


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

Comment By: Clemens Katzer (cleka)
Date: 2008-08-18 20:37

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

Actually the real question is, why does the preview show it wrong
but the battle does it right?
So this bug could be left open as reminder that those issues should
both use the same code...

-Clemens


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

Comment By: Clemens Katzer (cleka)
Date: 2008-08-18 19:09

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


Fixed in r3320. Leaving it open til next public build, as usual...



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

Comment By: Nobody/Anonymous (nobody)
Date: 2008-07-29 18:25

Message:
Logged In: NO 

I've noticed that too.  Currently testing a patch.  Appears to occur with
Brambles only.  Which Variant were you using?

-Ed.

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

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

Bugs item #1859016, was opened at 2007-12-27 19:33
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1859016&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: Done key and box disabled ?randomly?

Initial Comment:
dec 23, 2007 version 

During the mustering phase the "done" button and the "d" key are disabled stopping the game on that phase.

The only solution I've found is to save the game and reload it to be able to close out and move past that phase.

I just registered under jde...@ya....

Great game!  

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

>Comment By: Clemens Katzer (cleka)
Date: 2008-08-23 14:32

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


Now the Done button, menu item and "D" key shortcut should be 
always in sync and during game always right;

Only situation is that directly after a game was loaded it might
be wrong (not active, even if one could be done if one moved a legion
before saving).

Closing this here.


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

Comment By: Clemens Katzer (cleka)
Date: 2008-08-11 22:51

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

Actually in a later change the situation changed again:
Now the Done button and menu item are always in sync (menu item was still

randomly wrong as before), but situations have been reported that since
that 
change sometimes the en-/disabled state is wrong (not clear when and why
exactly).

As workaround to be able to continue the game there is now a "forced Done"
menu
item, in a case that Done button is disabled even if it's by the rules
"ok" to
be Done. (Server get's it right and thus accepts the "Done" message, 
just on client side something goes wrong...


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

Comment By: Clemens Katzer (cleka)
Date: 2007-12-27 20:27

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


Yes, this problem has been visible in the "first" build on december 24,
but you say december 23. Perhaps time zone difference?

Before the build on 24., the previous one was from september.

Late evening 24. I did another build and uploaded it to sourceforge.
This should 1) fix the problem and 2) for worst case additionally
it has a "Force Done" menu item.

Can you try again - possibly start the web start icon two times,
until it says "checking for update" and downloads the new version.

Unfortunately we name our builds only by date ;-)
- but you can see whether you have the first or second
build from whether it has a "Forced Done" menu item in phase menu.


Regards,

Clemens




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

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

Bugs item #700478, was opened at 2003-03-09 22:22
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=700478&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: 8
Private: No
Submitted By: David desJardins (daviddesj)
Assigned to: Clemens Katzer (cleka)
Summary: mandatory strike skipped

Initial Comment:
A player managed to end his strike phase without taking
his mandatory strikes.  This shouldn't be possible.

Here's the relevant segment of the battle log.  Note
that Purple's Cyclops in E3 never takes a strike at the
Ranger in D4, but the Ranger does take a counterstrike!

I've included the complete game log as an attachment.

Steve's battle turn, number 3
Battle phase advances to Move
- removeCreature() Pu06(6): Cyclops* Cyclops* Gargoyle
: Cyclops
- revealCreatures() for Pu06(6): Cyclops* Cyclops*
Gargoyle [Cyclops]
- From client Steve: doBattleMove ~ 154 ~ E3
Cyclops moves from D2 to E3
- From client Steve: doBattleMove ~ 110 ~ F2
Gargoyle moves from D1 to F2
- From client Steve: undoBattleMove ~ F2
Gargoyle undoes move and returns to D1
- From client Steve: doBattleMove ~ 110 ~ F1
Gargoyle moves from D1 to F1
- From client Steve: doneWithBattleMoves
Battle phase advances to Fight
- From client Steve: doneWithBattleMoves
Battle phase advances to Strikeback
- From client DavidF: leaveCarryMode
- From client DavidF: strike ~ 99 ~ E3
Ranger in D4 strikes Cyclops in Brambles hex E3 with
strike number 3 : 2666: 3 hits
- From client DavidF: doneWithStrikes


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

>Comment By: Clemens Katzer (cleka)
Date: 2008-08-23 14:27

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


Now visible in Public Build 2008-08-28 => Closing this.

-CleKa


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

Comment By: Clemens Katzer (cleka)
Date: 2008-08-13 20:20

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


Fixed in r3309 (no public build yet).

Server does now check that it's really BattleMove phase.


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

Comment By: David Ripton (dripton)
Date: 2003-03-11 01:15

Message:
Logged In: YES 
user_id=9425

Right.  doneWith* should only end the matching phase, not
whatever phase it happens to be.

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

Comment By: David desJardins (daviddesj)
Date: 2003-03-10 23:57

Message:
Logged In: YES 
user_id=718698

Regardless of client/server sync, doneWithBattleMoves
shouldn't end his strike phase at all, right?


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

Comment By: David Ripton (dripton)
Date: 2003-03-10 17:55

Message:
Logged In: YES 
user_id=9425

Looks like client/server sync problems.

Two consecutive doneWithBattleMoves, no doneWithStrikes from
Steve.

We have code to prevent doneWithStrikes with forced strikes
remaining, but it looks like it got bypassed here.

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

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

Bugs item #1964752, was opened at 2008-05-15 21:12
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1964752&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: 5
Private: No
Submitted By: Clemens Katzer (cleka)
Assigned to: Clemens Katzer (cleka)
Summary: Changing scale value sometimes causes exception

Initial Comment:

When one changes the scale value in Preferences window and presses apply, sometimes this causes an exception.

Exception in thread "AWT-EventQueue-0" java.lang.NumberFormatException: null
        at java.lang.Integer.parseInt(Integer.java:415)
        at java.lang.Integer.parseInt(Integer.java:497)
        at net.sf.colossus.client.Client$15.stringOptionChanged(Client.java:991)
        at net.sf.colossus.util.Options.triggerStringOption(Options.java:563)
        at net.sf.colossus.util.Options.setOption(Options.java:289)
        at net.sf.colossus.util.Options.setOption(Options.java:308)
        at net.sf.colossus.client.PreferencesWindow$ScaleValue.actionPerformed(PreferencesWindow.java:557)


Looks like it happens then when there is no value for that in the players cf file (e.g. when I deleted *all* cf files).

This is in r3271 -- e.g. also in current experimental trunk build (r3268).



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

>Comment By: Clemens Katzer (cleka)
Date: 2008-08-23 14:25

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


Now visible in Public Build from 2008-08-22.

 => Closing this item.

-CleKa


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

Comment By: Clemens Katzer (cleka)
Date: 2008-05-16 23:12

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


Fixed in r3272.


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

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

Bugs item #1702874, was opened at 2007-04-18 14:48
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1702874&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: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Clemens Katzer (cleka)
>Assigned to: Clemens Katzer (cleka)
Summary: Done action not necessarily in right state after game load

Initial Comment:

1) they are not always in sync
Only the Done button is (during normal playing) always en- or disabled properly according to whether it would be ok to be "done" in that moment or not. Menu item and D action key are mostly all the time active; using them would in most cases cause a client messages, perhaps even a nak.

2) after reloading a saved game
All three of them might not be right directly after loading a saved game. This is because the state of them
is modified based on messages coming from server.
Example: Move one legion and save. Quit, reload saved
game. Done button is disabled, eventhough the one legion had been moved (and you can't move it any more, nor undo that). Doing one move, and undo that - you are back to "Done disabled".
"Luckily", right now the "D" can still be used if button is (falsely) disabled, so one is not stuck forever. But one needs to know that :)



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

>Comment By: Clemens Katzer (cleka)
Date: 2008-08-23 14:17

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


They should now always be in sync and in right state, 
except possibly directly after loading a game.

Done button on BattleBoard is also always active even
if one is not ready to be "Done" (e.g. forced strikes remain).

So, keeping this open for the "load game" issue.

-CleKa



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

Comment By: Clemens Katzer (cleka)
Date: 2008-04-06 15:25

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


Done button, menu item and "D" key availability are now in sync;
still they might be wrong state e.g. after loading a game where
legions were moved before saving.

For that purpose there is now a "Forced Done" menu item. One can use
it when the GUI would not allow to be Done but you are sure it should
be ok to be. If you're wrong, you'll get a popup message telling
the reason why the server rejects it :)



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

Comment By: Peter Becker (peterbecker)
Date: 2007-12-24 04:30

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

The first part of this issue should be fixed -- the only thing that gets
enabled/disabled is the action now, which means everything should be in
sync. I haven't looked into the second part of the issue yet -- its
severity could be worse now that the different ways of calling "Done" are
in sync, I'll increase the priority due to that.

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

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

Bugs item #1608709, was opened at 2006-12-04 21:13
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1608709&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: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Clemens Katzer (cleka)
Summary: Problem mustering when choice

Initial Comment:
There is a problem when mustering: When you muster, you sometimes have the option to choose which creature or set of creatures you prefer to show to the other players when mustering the new creature. When this selection dialog appears, you don't need to select anything, you can just press D for Done, and the game will continue, with the selection dialog still open.

BTW, sometimes the Done button is disabled, while the Done is enabled in the menu and the shortcut key D is enabled.

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

>Comment By: Clemens Katzer (cleka)
Date: 2008-08-23 14:15

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

Fixed in r3330 and visible in public build 2008-08-22.
One can't bypasss the dialog with D key any more.

Done button, menu item and D key (MasterBoard) are now always 
in sync and should be always right according to game state,
except directly after loading a game:

[ 1702874 ] Done action not necessarily in right state after game load

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

Closing this here.

-CleKa

(BTW the Done button on the BattleBoard is another issue, sometimes
active
even if one can't be done... e.g. game is still waiting about decision 
whether and where to put carries, or forced strikes remain).


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

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

Bugs item #1175858, was opened at 2005-04-03 18:53
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1175858&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: Out of Date
Priority: 5
Private: No
Submitted By: Chris Camfield (ccamfield)
>Assigned to: Clemens Katzer (cleka)
Summary: Invisible stack marker

Initial Comment:
On playing a 6-player regular Titan game, one of 
the initial black stack markers (sorry, I didn't notice 
if it was the very first one) was transparent rather 
than possessing an image.

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

>Comment By: Clemens Katzer (cleka)
Date: 2008-08-22 20:42

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

After asking from original submitter this seems to be out of date.

=> Closing it.

-CleKa


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

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

Bugs item #1895129, was opened at 2008-02-17 00:20
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=1895129&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: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Clemens Katzer (cleka)
Summary: carryover gui issue

Initial Comment:
If when presented with the carryover prompt you click someplace outside of the prompt then you forgoe your carryover even if you click on a selection that requests it. This happens in current cvs, though has been going on for a long time. (When I first started suspecting this behavior, I wasn't sure that I had really clicked on the right menu item.)

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

>Comment By: Clemens Katzer (cleka)
Date: 2008-08-22 18:45

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


Mostly solved, but one tiny issue with it still:

Implemented "can click to carry" and clicking anywhere else does not harm
in r3328.
Only closing the dialog with the "x" leaves the targets highlighted and
there's no way
out of that state except clicking one of the targets.
Didn't get the GUI make call the WindowClosing method, for some reason...

So, this bug might stay open as reminder until that issue is resolved
too...

-CleKa


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

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

Feature Requests item #558825, was opened at 2002-05-21 22:48
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351939&aid=558825&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: 4
Private: No
Submitted By: Bill Barksdale (wcbarksdale)
>Assigned to: Clemens Katzer (cleka)
Summary: Clickable spillover

Initial Comment:
It would be nice if you could click on the legion you would like to spill to rather than being forced to hunt for it.  The same is true for the decision to strike up.

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

>Comment By: Clemens Katzer (cleka)
Date: 2008-08-22 17:58

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

For carries (spillover) implemented in r3328.
It's now a non-modal dialog (was already), and valid targets may be also
clicked 
on the board (additionally to the dialog); clicking anywhere else does NOT
terminate
the chance to carry excees damage (as it did before).

Just don't close the dialog with the "x" dialog, that's not good (yet;-)

For "strike up" (strike penalties??) it's not done, and it's somewhat more
complicated there.

-CleKa


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

Comment By: David Ripton (dripton)
Date: 2002-05-22 01:04

Message:
Logged In: YES 
user_id=9425

We used to do carries via clicking on hexes, but it confused
people.  The current modal dialog is ugly but straightforward.

The optimal solution would be a non-modal dialog off to the
side, along with hex highlighting.  It's a bit of work, though.

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

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

Feature Requests item #491247, was opened at 2001-12-10 20:51
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351939&aid=491247&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: 3
Private: No
Submitted By: Jeff Chunko (jchunko)
>Assigned to: Clemens Katzer (cleka)
Summary: Closing a question box

Initial Comment:
Closing a question box (like the battle board query 
about wether to take a penalty to hit) should "undo" 
the action, not choose the default option.

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

>Comment By: Clemens Katzer (cleka)
Date: 2008-08-22 17:50

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


Fixed in r3326 for the Pick Strike penalty dialog:

Pick Strike Penalty dialog: added "cancel", and cancel or closing window 
now do cancel the strike, rather than striking with default. 
This is also related to:  [ 491247 ] Closing a question box

Are there any other cases where this applies? I don't see any right now.
The one coming to my mind all cancel, except the negotiatin, flee &
concede
dialog and I would judge, there a "cancel" after you've seen the content
is against the rules...

If you or someone else comes up with one, he or she should make a new
feature
request for that one, then.

This one here will be closed 
- because I believe we will have a public build soon...  ;-)

-Cleka


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

Comment By: David Ripton (dripton)
Date: 2002-02-02 00:50

Message:
Logged In: YES 
user_id=9425

Yeah, you're probably right.  Some of those actions are not
currently undoable, so this is a bit of work.

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

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

Bugs item #2046854, was opened at 2008-08-11 22:40
Message generated for change (Comment added) made by cleka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101939&aid=2046854&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: 7
Private: No
Submitted By: Clemens Katzer (cleka)
Assigned to: Clemens Katzer (cleka)
Summary: If Titan is killed in negotiation, game does not end

Initial Comment:

If in a negotiation a Titan is killed, the handle-negotiation code does not notice that the player is eliminated and thus game should be over.

After I fixed the Negotiation stuff, so that clicking "Accept" actually works, I tried it (in a 2 human players game) with a Titan-vs-Titan fight. Offer was kill the one legion and most of the other legion.

Negotiation was matched and processed and ended the battle, remaining creatures were back on board, but the game was not ended, no "xxx wins" dialog - the other player still had a legion on board, but no legion with a titan.

This is in r3298.


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

>Comment By: Clemens Katzer (cleka)
Date: 2008-08-20 17:27

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


Fixed in 3323.

Closing because it was not visible in last public build, 
thus it's not needed to wait for next public build.

-CleKa


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

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