colossus-developers Mailing List for Colossus

Colossus
 
 
https://www.google.com/search?q=c...@li...
 
 
 
 

 

colossus developers

https://bit.ly/36itIb7
















Monitor arms let you position your display (or displays) at any height or angle, and re-position…
Preparing also means knowing what type of setup will be used. Will the mics be handheld or clip-on? Will you have stools? Seats? A podium? How close will the audience be to the stage?

pgmcb nuagist Rexanne ovorhomboid

dMenno superstructures archways infanticidal

colossus developers
http://fightfinger.xyz/4dMoqXL/expansionary/














jderekmiller
relocate















When you splurge on a cheese that's $20 per pound, you're going to want to keep it fresh for as long as you possibly can. But that doesn't mean you have to spend another $9 for a box of cheese papers. In fact, you can preserve cheese well with products you probably already have at home.
ankles growers arbitrated
stripier chestnuts




hkqpt predevised punts The Holiday 'I Overdid It' Syndrome: 6 Ways to Keep Spending, Eating and Indulging in Check 
 LearnVest stemlike

lyaomoplate anticipating In all, the courses will take over 90 hours to complete, but if you've ever wanted to get serious about making your own app, there's no time like the present. determining hook-armed

good afternoon Colossus  https://goo.gl/TWNf1E     Craig

Hey Colossus https://goo.gl/QG6J6d    emprdranathi

Hi colossus

http://followhelen.com/Dick.php?general=1u3nfd7h0pa0


Craig Lish

Hi colossus


http://www.anamorphose-conseil.fr/pet.php?ride=1pxhkv3x5f8p9t

Hi folks,

I have made a new "official" build - 2016-01-21.

Enjoy!


All the best,
-Clemens

Hello world,

I have made a new "Public Build". Please give it a try!


Thx,
Clemens

On 11/26/2015 03:08 AM, Nor...@gm... wrote:

> i've a general question. i'm interested in the general stategy an AI
> player has during the battle on battlelands.
>  
> Is there anywhere a document where  something like a priority list or an
> algorith is given which units are attacked prefered (within the rules of
> course) and which fiels are occupied depending on AI engine and/or
> battle land and/or unit?
>  
> I do not need necessarily programming code, I'm only searching for
> general rules for the battles. If something is also available for the
> strategic map in would be nice, but this is secondarily.

Sorry, no.  Here's the best I can do in a few minutes:

Things that make a battle AI for Titan hard:

1. Branching factor.  If you have a defending legion of 7 different
skill 4 creatures entering the plains, each can visit 3+4+5+6 = 18
hexes.  So there are 18*17*16*15*14*13*12 = 160392960 possible moves.
(Compared to something like 40 possible moves in a typical chess
position.)  Just enumerating them all takes a long time.  Meaningfully
evaluating all the moves just for one turn in a reasonable amount of
time is pretty hard.

2. Randomness.  You can't say "if I do this then this will happen."  You
have to say "if I do this then this will happen with probability p."  In
combination with the branching factor, this makes a brute force tree
search AI, where you try all combinations of moves and counter-moves
several turns ahead and evaluate at the end, impossible.

3. Strategic concerns.  The battle is not the whole game (unless it's
Titan on Titan between the last 2 players).  So there are other concerns
besides just winning, or just damaging the opponent as much as possible.
 Sometimes you want to avoid summoning an angel because another battle
needs it more.  Sometimes you want to avoid recruiting a reinforcement
because you're probably going to lose anyway and don't want to hand over
more points.  Often you want to flee to give fewer points, or keep the
opponent from recruiting.  (Note: SimpleAI doesn't really take this into
account.  There's a simple rule for fleeing based on the relative values
of the legions -- if you have no chance, flee.  Otherwise it fights as
well as it can, even when that's dumb.  But there's a newer AI called
ExperimentalAI that has multiple objectives and switches its behavior.)

Anyway, our original AI (SimpleAI) is a bunch of heuristics.  The first
goal is to get the entire legion on board.  (And if it's not possible
because of slow creatures in unfriendly terrain, at least get the better
creatures on board.)  Another major goal (at which we've historically
been bad) is to protect the Titan.  (But this is another tradeoff
because the Titan is one of the stronger characters, so you want to use
it, just not expose it too much.)  Another one is for the attacker to
press the attack to avoid a time loss.  (But a time loss is better than
a regular loss.)

So what we do is allow each creature to independently figure out the hex
it wants to move to, not taking its mobile allies into account.
(Because creature moves have a much smaller branching factor than
whole-legion moves.  In the case above, you end up with 7*18=126
creature moves.)  It's based on a lot of heuristics like wanting to get
to good terrain and avoid bad terrain, wanting to close with the enemy
if attacking, wanting to damage enemies and avoid damage to itself
(which favors rangestriking), etc.  Once each creature has figured out
its 7 favorite hexes in isolation (7 because if we have 7 creatures in
the legion and they all want the same hexes, one of them will have to
settle for its 7th choice), we can construct legion moves with a
branching factor of no more than 7 ** 7 = 823543.  Then we can start
evaluating those, in random order so that if we run out of time we've at
least looked at a reasonable sample.  When we finally pick a legion
move, we then have to figure out an order of creature moves that makes
it possible, but that's pretty easy.

The actual evaluation function in Colossus isn't very good.  There are
36 constants that you can look at in:

https://github.com/cleka/colossus-titan/blob/adf5bab8826493b77387126711e4c2afbf3f83fa/Colossus/core/src/main/java/net/sf/colossus/ai/helper/BattleEvalConstants.java

It's very hard to hand-tune a combination of 36 constants.  In Slugathon
I created a genetic algorithm to tune them -- basically each AI consists
of a randomized vector of these constants, and I track game results and
play a bunch of automated AI games, and the AIs that win more get to
breed, and in theory after many generations you get a better AI.  While
it's neat, the problem is that this technique really only finds a local
optimum rather than truly novel ideas; you're only changing constants,
not code.  Actually coming up with new heuristics takes human thinking.
 Another problem is that most of my test data is AI vs. AI fights, so
we're tuning the AI to beat other AIs, not to beat humans (which is the
real goal).

-- 
David Ripton    dr...@ri...

Hello Norbert,

I am afraid for the battles, there is no such document, only the 
programming code. And it is not so much oriented in "priority lists", 
rather on calculating points (good or bad) for certain aspects.

The overall approach I would summarize as this (other developers might 
have a slightly different view ;-)  :

It generates (mostly randomly) combinations of possible "which creature 
could go where (in theory, based on it's reach)". For each such 
combination, it verifies, is there actually a sequence that all 
creatures could reach those places. For working ones, it evaluates a 
number of aspects, which results in a value for this combination, 
keeping the best one in mind. If there is still time, it generates a 
next set of combinations and does the same. When time is over, it does 
the combination with the best value.


Examples for points to be given:

- non-native creature on field that does damage (tundra): minus
- non-native creature on field that causes disadvantage (bramble, sand, 
below slope/dune/wall): minus
- native creature on field where it has advantage (bramble, dune): plus
- titan in risk of being hit: minus
- titan has very high power factor (e.g. 1000 points, titan power = 
16): less vulnerable, reduces the titan in risk number
- more-than-one against one other: plus
- one-against-several: minus
- battle turn number grows, and is attacker: more aggressively
- defender might give minus for creatures that could reinforce being in 
danger

And so on. Above are just examples I made up. Our different AIs mostly 
differ in the parameters which aspect gives which value.

I don't even know whether there is a specific evaluation for "which 
creature to aim for most". I remember there was work ongoing to define 
certain primary overall "objectives" (e.g.: protect titan; strip vs. 
destroy; kill first creature quickly to be able to summon). There might 
be something to give points for being able to strike e.g. a) strongest 
creatures or b) native creatures, i.e. those which could reinforce.

One of the AIs tries to do some kind of "genetic" approach, by 
generating the next set not "merely randomly" but instead by doing 
crossovers between some very good ones and perhaps some very bad ones 
from previous sets.


But I am not sure whether our AIs are a good example to study (or even 
take as model for building an own), because generally they are 
considered rather weak. Even a mediocre player will more often win than 
loose. If you develop a good approach, let us know, perhaps we can get 
better AIs from it.
Better yet, you are very welcome to develop your own AI and try out 
approaches. I am willing to guide you how to get started, or even 
discussions about pro or cons.


> If something is also available for the strategic map in would be 
> nice, but this is secondarily.

Some overall strategy guidelines you might find from this link:  
http://www.desjardins.org/titan/strategy.txt
It's intended for humans, though ;-)


Hope that helps,
with Greetings to Good Old Germany,
Clemens



On 2015-11-26 10:08, Nor...@gm... wrote:
> Dear developers,
>
> i've a general question. i'm interested in the general stategy an AI
> player has during the battle on battlelands.
>
> Is there anywhere a document where something like a priority list or
> an algorith is given which units are attacked prefered (within the
> rules of course) and which fiels are occupied depending on AI engine
> and/or battle land and/or unit?
>
> I do not need necessarily programming code, I'm only searching for
> general rules for the battles. If something is also available for the
> strategic map in would be nice, but this is secondarily.
>
> Best regards.
> Norbert

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>&nbsp;</div>

<div class="signature">Dear developers,</div>

<div class="signature">&nbsp;</div>

<div class="signature">i&#39;ve a general question. i&#39;m interested in the general stategy an AI player has during the battle on battlelands.</div>

<div class="signature">&nbsp;</div>

<div class="signature">Is there anywhere a document where&nbsp; something like a priority list or an algorith is given which units are attacked prefered (within the rules of course) and which fiels are occupied depending on AI engine and/or battle land and/or unit?</div>

<div class="signature">&nbsp;</div>

<div class="signature">I do not need necessarily programming code, I&#39;m only searching for general rules for the battles. If something is also available for the strategic map in would be nice, but this is secondarily.</div>

<div class="signature">&nbsp;</div>

<div class="signature">Best regards.</div>

<div class="signature">Norbert</div>

<div class="signature">&nbsp;</div>

<div class="signature">&nbsp;</div></div></body></html>

SnapCI goes back to JDK6: 
https://docs.snap-ci.com/the-ci-environment/languages/java/
CircleCI does the same: https://circleci.com/docs/environment#java

and so do Drone.io and Shippable:
  - http://docs.drone.io/java.html
  - http://docs.shippable.com/languages/#java

CodeShip goes back to 7 only: 
https://codeship.com/documentation/languages/java-and-jvm-based-languages/

And Wercker doesn't know Java: 
http://devcenter.wercker.com/docs/languages/index.html

There are others, but we are getting rather exotic by now.

Part of the problem might be a lack of an OpenJDK for Java 5. The other 
part is the age: even in Enterprise World I haven't seen anyone on Java 
5 for a while, Java 6 is pretty much gone, Java 7 is still deemed 
acceptable it seems -- despite being out of public updates.

Java 5 ended 6 years ago, that's a long time in IT :-)

    Peter


On 28/08/2015 7:31 PM, Peter Becker wrote:
> Travis goes back to OpenJDK 6, but not further: 
> http://docs.travis-ci.com/user/languages/java/
>
> I'll check for some alternatives, but I JDK 5 is pretty ancient by now.
>
> Peter
>
> On 28 August 2015 7:19:33 pm AEST, Clemens Katzer 
> <cle...@cl...> wrote:
>
>
>     On 2015-08-28 11:07, Peter Becker wrote:
>
>         You might want to see if you can build against an older JDK on
>         Travis or an equivalent service. I'm writing this on the
>         phone, so it's a bit tricky to check - I can do some research
>         on the weekend if you want me 
>
>
>     yes, that would be nice.
>
>     Thx,
>     Clemens
>
>         to. Peter On 28 August 2015 3:58:32 pm AEST, Clemens Katzer
>         <cle...@cl...> wrote:
>
>             On 2015-08-28 04:19, Barrie Treloar wrote:
>
>                 On 28 August 2015 at 07:07, Peter Becker
>                 <pe...@pe... [2]> wrote:
>
>                     One note of warning: unless you compile against a
>                     corresponding JDK 
>
>             Good point. So at least should compile it against an 1.5
>             every then and now.
>
>                     nothing will stop you from picking up a method
>                     that won't be in an earlier JDK. The result is a
>                     NoSuchMethodException (or something like that) at
>                     runtime. And there is plenty of innocent looking
>                     stuff like this one, which was introduced in 1.6: 
>
>         http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty
>
>
>                 [1]()
>
>                     [1] The only safe ways are to compile against the
>                     target JDK or to use static code analysis tools. 
>
>             Every then and now against a 1.5 JRE is much easier. Could
>             have one in a virtual machine; or, even on main PC, it
>             just needs to be unpacked in some folder, right? So no
>             need to "officially" install with Yum. And, github has a
>             Jenkins, right? So one job there could do the job. Though
>             I would have to push more often, but then, main thing is
>             to ensure it before making a build that the whole wild
>             world will use. thanks, but... I've not used it but maven
>             animal sniffer plugin will throw exceptions in case like
>             this. 
>
>         Links: ------ [1]
>         http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty
>         [2]
>         https://lists.sourceforge.net/lists/listinfo/colossus-developers
>         [3] http://stackoverflow.com/a/4451057/552958 
>
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

Travis goes back to OpenJDK 6, but not further: http://docs.travis-ci.com/user/languages/java/

I'll check for some alternatives, but I JDK 5 is pretty ancient by now.

   Peter

On 28 August 2015 7:19:33 pm AEST, Clemens Katzer <cle...@cl...> wrote:
>
>
>On 2015-08-28 11:07, Peter Becker wrote:
>> You might want to see if you can build against an older JDK on Travis
>> or an equivalent service. I'm writing this on the phone, so it's a 
>> bit
>> tricky to check - I can do some research on the weekend if you want 
>> me
>
>yes, that would be nice.
>
>Thx,
>Clemens
>
>> to.
>>
>>  Peter
>>
>> On 28 August 2015 3:58:32 pm AEST, Clemens Katzer
>> <cle...@cl...> wrote:
>>
>>> On 2015-08-28 04:19, Barrie Treloar wrote:
>>>> On 28 August 2015 at 07:07, Peter Becker <pe...@pe...
>>>> [2]>
>>>> wrote:
>>>>
>>>>> One note of warning: unless you compile against a corresponding
>>>>> JDK
>>>
>>> Good point. So at least should compile it against an 1.5 every then
>>> and
>>> now.
>>>
>>>>> nothing will stop you from picking up a method that won't be in
>>>>> an
>>>>> earlier JDK. The result is a NoSuchMethodException (or
>>>>> something
>>>>> like
>>>>> that) at runtime.
>>>>>
>>>>> And there is plenty of innocent looking stuff like this one,
>>>>> which
>>>>> was
>>>>> introduced in 1.6:
>>>>
>>>>
>>>
>> 
>>
>http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty
>>>> [1]()
>>>>
>>>>> [1]
>>>>>
>>>>> The only safe ways are to compile against the target JDK or to
>>>>> use
>>>>> static code analysis tools.
>>>
>>> Every then and now against a 1.5 JRE is much easier. Could have one
>>> in a virtual machine; or, even on main PC, it just needs to be
>>> unpacked
>>> in some folder, right? So no need to "officially" install with Yum.
>>>
>>> And, github has a Jenkins, right? So one job there could do the job.
>>> Though I would have to push more often, but then, main thing is to
>>> ensure it
>>> before making a build that the whole wild world will use.
>>>
>>> thanks, but...
>>>
>>> I've not used it but maven animal sniffer plugin will throw
>>> exceptions
>>> in case like this.
>>
>>
>> Links:
>> ------
>> [1] 
>>
>http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty
>> [2] https://lists.sourceforge.net/lists/listinfo/colossus-developers
>> [3] http://stackoverflow.com/a/4451057/552958

On 2015-08-28 11:07, Peter Becker wrote:
> You might want to see if you can build against an older JDK on Travis
> or an equivalent service. I'm writing this on the phone, so it's a 
> bit
> tricky to check - I can do some research on the weekend if you want 
> me

yes, that would be nice.

Thx,
Clemens

> to.
>
>  Peter
>
> On 28 August 2015 3:58:32 pm AEST, Clemens Katzer
> <cle...@cl...> wrote:
>
>> On 2015-08-28 04:19, Barrie Treloar wrote:
>>> On 28 August 2015 at 07:07, Peter Becker <pe...@pe...
>>> [2]>
>>> wrote:
>>>
>>>> One note of warning: unless you compile against a corresponding
>>>> JDK
>>
>> Good point. So at least should compile it against an 1.5 every then
>> and
>> now.
>>
>>>> nothing will stop you from picking up a method that won't be in
>>>> an
>>>> earlier JDK. The result is a NoSuchMethodException (or
>>>> something
>>>> like
>>>> that) at runtime.
>>>>
>>>> And there is plenty of innocent looking stuff like this one,
>>>> which
>>>> was
>>>> introduced in 1.6:
>>>
>>>
>>
> 
> http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty
>>> [1]()
>>>
>>>> [1]
>>>>
>>>> The only safe ways are to compile against the target JDK or to
>>>> use
>>>> static code analysis tools.
>>
>> Every then and now against a 1.5 JRE is much easier. Could have one
>> in a virtual machine; or, even on main PC, it just needs to be
>> unpacked
>> in some folder, right? So no need to "officially" install with Yum.
>>
>> And, github has a Jenkins, right? So one job there could do the job.
>> Though I would have to push more often, but then, main thing is to
>> ensure it
>> before making a build that the whole wild world will use.
>>
>> thanks, but...
>>
>> I've not used it but maven animal sniffer plugin will throw
>> exceptions
>> in case like this.
>
>
> Links:
> ------
> [1] 
> http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty
> [2] https://lists.sourceforge.net/lists/listinfo/colossus-developers
> [3] http://stackoverflow.com/a/4451057/552958

You might want to see if you can build against an older JDK on Travis or an equivalent service. I'm writing this on the phone, so it's a bit tricky to check - I can do some research on the weekend if you want me to.

  Peter

On 28 August 2015 3:58:32 pm AEST, Clemens Katzer <cle...@cl...> wrote:
>
>
>On 2015-08-28 04:19, Barrie Treloar wrote:
>> On 28 August 2015 at 07:07, Peter Becker <pe...@pe... [2]>
>> wrote:
>>
>>> One note of warning: unless you compile against a corresponding JDK
>
>Good point. So at least should compile it against an 1.5 every then and
>
>now.
>
>
>>> nothing will stop you from picking up a method that won't be in an
>>> earlier JDK. The result is a NoSuchMethodException (or something
>>> like
>>> that) at runtime.
>>>
>>> And there is plenty of innocent looking stuff like this one, which
>>> was
>>> introduced in 1.6:
>>>
>> 
>>
>http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty()
>>> [1]
>>>
>>> The only safe ways are to compile against the target JDK or to use
>>> static code analysis tools.
>
>Every then and now against a 1.5 JRE is much easier. Could have one
>in a virtual machine; or, even on main PC, it just needs to be unpacked
>in some folder, right? So no need to "officially" install with Yum.
>
>And, github has a Jenkins, right? So one job there could do the job.
>Though I would have to push more often, but then, main thing is to 
>ensure it
>before making a build that the whole wild world will use.
>
>
>thanks, but...
>
>> I've not used it but maven animal sniffer plugin will throw 
>> exceptions
>> in case like this.
>
>If somebody is willing to port this to maven - be my guest. I won't do 
>that
>and struggle with a "dubious" (well at least badly documented) plugin 
>if
>there are easier ways to achieve things.
>
>Besides, what I hear Maven is "obsolete", Cradle is "in" now... No?
>
>
>> The documentation is not great,
>> http://stackoverflow.com/a/4451057/552958 [3] should give you enough
>> to get going to enforce this on the minimum jre you want to run on 
>> and
>> allow some comfort on the jdk you want to build against.
>>
>
>So thank you very much for your advice/suggestions, but I will try
>one of the above. Probably unpack the JRE to somewhere.
>
>
>All the best,
>Clemens
>
>
>
>------------------------------------------------------------------------------
>_______________________________________________
>Colossus-developers mailing list
>Col...@li...
>https://lists.sourceforge.net/lists/listinfo/colossus-developers

I personally like adjusting subjects on the original threads, I tend to put a "was: ... " into the first line.

But that's me who uses decent mail clients whenever I can :-) I've certainly encountered opposition.

  Peter

On 28 August 2015 4:01:26 pm AEST, Clemens Katzer <cle...@cl...> wrote:
>
>BTW, about etiquette: would it be abd style to change the mail subject 
>to what it's now really about?
>Because, it might screw up some peoples mail client, who looks at the 
>original header. (or something?)
>
>For me it makes more sense to have the right subject there; for those 
>whose mail client does not handle
>it "old header" style, it's better, and the others, well they are not 
>much worse than before...
>
>
>I guess the best way would be to start a new mail, copy-pasting the 
>relevant part(s) into that.
>
>
>Thanks,
>Clemens
>
>
>
>On 2015-08-28 00:37, Peter Becker wrote:
>> One note of warning: unless you compile against a corresponding JDK
>> nothing will stop you from picking up a method that won't be in an
>> earlier JDK. The result is a NoSuchMethodException (or something like
>> that) at runtime.
>>
>> And there is plenty of innocent looking stuff like this one, which 
>> was
>> introduced in 1.6:
>> 
>>
>http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty()
>>
>> The only safe ways are to compile against the target JDK or to use
>> static code analysis tools.
>>
>>     Peter
>>
>>
>> On 27/08/2015 3:10 PM, Clemens Katzer wrote:
>>>> My java6 choked on "JComboBox<String>", isn't that new in 7?
>>> Ah, right, that way. But that's only syntactic stuff.
>>>
>>> So, correction: No, it can't be compiled with Java 5 or 6, but it 
>>> can
>>> be compiled to be runnable on Java 5.
>>>
>>> (( the funny thing is, it compiles this code happily with java 7, 
>>> even
>>> if -source 1.7 is set (!!!) ))
>>>
>>>
>>> [clemens@myldaptop Colossus]$ grep level build.properties
>>> source.level=1.5
>>> target.level=1.5
>>> [clemens@myldaptop Colossus]$ ant clean jars
>>> Buildfile: /home/clemens/p/sf/github/coti/Colossus/build.xml
>>>
>>> cleanjars:
>>>      [delete] Deleting:
>>> /home/clemens/p/sf/github/coti/Colossus/Colossus.jar
>>>      [delete] Deleting:
>>> /home/clemens/p/sf/github/coti/Colossus/ColossusWeb.jar
>>>      [delete] Deleting:
>>> /home/clemens/p/sf/github/coti/Colossus/CmdlineClient.jar
>>>
>>> clean:
>>>      [delete] Deleting directory
>>> /home/clemens/p/sf/github/coti/Colossus/build/ant
>>>
>>> cleanjars:
>>>
>>> clean:
>>>
>>> init:
>>>       [mkdir] Created dir:
>>> /home/clemens/p/sf/github/coti/Colossus/build/ant/classes
>>>       [mkdir] Created dir:
>>> /home/clemens/p/sf/github/coti/Colossus/build/ant/testresults
>>>
>>> compile:
>>>       [javac] Compiling 284 source files to
>>> /home/clemens/p/sf/github/coti/Colossus/build/ant/classes
>>>       [javac] warning: [options] bootstrap class path not set in
>>> conjunction with -source 1.5
>>>       [javac] 1 warning
>>>
>>> compileVariants:
>>>       [javac] Compiling 17 source files to
>>> /home/clemens/p/sf/github/coti/Colossus/build/ant/classes
>>>       [javac] warning: [options] bootstrap class path not set in
>>> conjunction with -source 1.5
>>>       [javac] 1 warning
>>>
>>> jar:
>>>         [jar] Building jar:
>>> /home/clemens/p/sf/github/coti/Colossus/Colossus.jar
>>>         [jar] Updating jar:
>>> /home/clemens/p/sf/github/coti/Colossus/Colossus.jar
>>>         [jar] Updating jar:
>>> /home/clemens/p/sf/github/coti/Colossus/Colossus.jar
>>>
>>> webjar:
>>>         [jar] Building jar:
>>> /home/clemens/p/sf/github/coti/Colossus/ColossusWeb.jar
>>>
>>> ccj:
>>>         [jar] Building jar:
>>> /home/clemens/p/sf/github/coti/Colossus/CmdlineClient.jar
>>>
>>> jars:
>>>
>>> BUILD SUCCESSFUL
>>> Total time: 8 seconds
>>> [clemens@myldaptop Colossus]$ javac -version
>>> javac 1.7.0_45
>>> [clemens@myldaptop Colossus]$
>>>
>>>
>>>
>>> On 2015-08-26 23:04, Romain Dolbeau wrote:
>>>> 2015-08-26 21:54 GMT+02:00 Clemens Katzer <cle...@cl...
>>>> [1]>:
>>>>
>>>>>> The current code cannot be compiled with java 6 unfortunately.
>>>>> Actually it can. The build file and the jnlp file say it needs 
>>>>> 1.7,
>>>>> but
>>>>> there's nothing in the code that won't work with Java 5. As far as
>>>>> I
>>>>> know, at least :)
>>>> My java6 choked on "JComboBox<String>", isn't that new in 7?
>>>>
>>>> I haven't done any java in a long time, I could be very wrong.
>>>>
>>>> Cordially,
>>>>
>>>>   --
>>>>
>>>> Romain Dolbeau
>>>>
>>>> Links:
>>>> ------
>>>> [1] mailto:cle...@cl...
>>>
>>> 
>>>
>------------------------------------------------------------------------------
>>> _______________________________________________
>>> Colossus-developers mailing list
>>> Col...@li...
>>> https://lists.sourceforge.net/lists/listinfo/colossus-developers
>>
>>
>> 
>>
>------------------------------------------------------------------------------
>> _______________________________________________
>> Colossus-developers mailing list
>> Col...@li...
>> https://lists.sourceforge.net/lists/listinfo/colossus-developers
>
>
>------------------------------------------------------------------------------
>_______________________________________________
>Colossus-developers mailing list
>Col...@li...
>https://lists.sourceforge.net/lists/listinfo/colossus-developers

BTW, about etiquette: would it be abd style to change the mail subject 
to what it's now really about?
Because, it might screw up some peoples mail client, who looks at the 
original header. (or something?)

For me it makes more sense to have the right subject there; for those 
whose mail client does not handle
it "old header" style, it's better, and the others, well they are not 
much worse than before...


I guess the best way would be to start a new mail, copy-pasting the 
relevant part(s) into that.


Thanks,
Clemens



On 2015-08-28 00:37, Peter Becker wrote:
> One note of warning: unless you compile against a corresponding JDK
> nothing will stop you from picking up a method that won't be in an
> earlier JDK. The result is a NoSuchMethodException (or something like
> that) at runtime.
>
> And there is plenty of innocent looking stuff like this one, which 
> was
> introduced in 1.6:
> 
> http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty()
>
> The only safe ways are to compile against the target JDK or to use
> static code analysis tools.
>
>     Peter
>
>
> On 27/08/2015 3:10 PM, Clemens Katzer wrote:
>>> My java6 choked on "JComboBox<String>", isn't that new in 7?
>> Ah, right, that way. But that's only syntactic stuff.
>>
>> So, correction: No, it can't be compiled with Java 5 or 6, but it 
>> can
>> be compiled to be runnable on Java 5.
>>
>> (( the funny thing is, it compiles this code happily with java 7, 
>> even
>> if -source 1.7 is set (!!!) ))
>>
>>
>> [clemens@myldaptop Colossus]$ grep level build.properties
>> source.level=1.5
>> target.level=1.5
>> [clemens@myldaptop Colossus]$ ant clean jars
>> Buildfile: /home/clemens/p/sf/github/coti/Colossus/build.xml
>>
>> cleanjars:
>>      [delete] Deleting:
>> /home/clemens/p/sf/github/coti/Colossus/Colossus.jar
>>      [delete] Deleting:
>> /home/clemens/p/sf/github/coti/Colossus/ColossusWeb.jar
>>      [delete] Deleting:
>> /home/clemens/p/sf/github/coti/Colossus/CmdlineClient.jar
>>
>> clean:
>>      [delete] Deleting directory
>> /home/clemens/p/sf/github/coti/Colossus/build/ant
>>
>> cleanjars:
>>
>> clean:
>>
>> init:
>>       [mkdir] Created dir:
>> /home/clemens/p/sf/github/coti/Colossus/build/ant/classes
>>       [mkdir] Created dir:
>> /home/clemens/p/sf/github/coti/Colossus/build/ant/testresults
>>
>> compile:
>>       [javac] Compiling 284 source files to
>> /home/clemens/p/sf/github/coti/Colossus/build/ant/classes
>>       [javac] warning: [options] bootstrap class path not set in
>> conjunction with -source 1.5
>>       [javac] 1 warning
>>
>> compileVariants:
>>       [javac] Compiling 17 source files to
>> /home/clemens/p/sf/github/coti/Colossus/build/ant/classes
>>       [javac] warning: [options] bootstrap class path not set in
>> conjunction with -source 1.5
>>       [javac] 1 warning
>>
>> jar:
>>         [jar] Building jar:
>> /home/clemens/p/sf/github/coti/Colossus/Colossus.jar
>>         [jar] Updating jar:
>> /home/clemens/p/sf/github/coti/Colossus/Colossus.jar
>>         [jar] Updating jar:
>> /home/clemens/p/sf/github/coti/Colossus/Colossus.jar
>>
>> webjar:
>>         [jar] Building jar:
>> /home/clemens/p/sf/github/coti/Colossus/ColossusWeb.jar
>>
>> ccj:
>>         [jar] Building jar:
>> /home/clemens/p/sf/github/coti/Colossus/CmdlineClient.jar
>>
>> jars:
>>
>> BUILD SUCCESSFUL
>> Total time: 8 seconds
>> [clemens@myldaptop Colossus]$ javac -version
>> javac 1.7.0_45
>> [clemens@myldaptop Colossus]$
>>
>>
>>
>> On 2015-08-26 23:04, Romain Dolbeau wrote:
>>> 2015-08-26 21:54 GMT+02:00 Clemens Katzer <cle...@cl...
>>> [1]>:
>>>
>>>>> The current code cannot be compiled with java 6 unfortunately.
>>>> Actually it can. The build file and the jnlp file say it needs 
>>>> 1.7,
>>>> but
>>>> there's nothing in the code that won't work with Java 5. As far as
>>>> I
>>>> know, at least :)
>>> My java6 choked on "JComboBox<String>", isn't that new in 7?
>>>
>>> I haven't done any java in a long time, I could be very wrong.
>>>
>>> Cordially,
>>>
>>>   --
>>>
>>> Romain Dolbeau
>>>
>>> Links:
>>> ------
>>> [1] mailto:cle...@cl...
>>
>> 
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Colossus-developers mailing list
>> Col...@li...
>> https://lists.sourceforge.net/lists/listinfo/colossus-developers
>
>
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

On 2015-08-28 04:19, Barrie Treloar wrote:
> On 28 August 2015 at 07:07, Peter Becker <pe...@pe... [2]>
> wrote:
>
>> One note of warning: unless you compile against a corresponding JDK

Good point. So at least should compile it against an 1.5 every then and 
now.


>> nothing will stop you from picking up a method that won't be in an
>> earlier JDK. The result is a NoSuchMethodException (or something
>> like
>> that) at runtime.
>>
>> And there is plenty of innocent looking stuff like this one, which
>> was
>> introduced in 1.6:
>>
> 
> http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty()
>> [1]
>>
>> The only safe ways are to compile against the target JDK or to use
>> static code analysis tools.

Every then and now against a 1.5 JRE is much easier. Could have one
in a virtual machine; or, even on main PC, it just needs to be unpacked
in some folder, right? So no need to "officially" install with Yum.

And, github has a Jenkins, right? So one job there could do the job.
Though I would have to push more often, but then, main thing is to 
ensure it
before making a build that the whole wild world will use.


thanks, but...

> I've not used it but maven animal sniffer plugin will throw 
> exceptions
> in case like this.

If somebody is willing to port this to maven - be my guest. I won't do 
that
and struggle with a "dubious" (well at least badly documented) plugin 
if
there are easier ways to achieve things.

Besides, what I hear Maven is "obsolete", Cradle is "in" now... No?


> The documentation is not great,
> http://stackoverflow.com/a/4451057/552958 [3] should give you enough
> to get going to enforce this on the minimum jre you want to run on 
> and
> allow some comfort on the jdk you want to build against.
>

So thank you very much for your advice/suggestions, but I will try
one of the above. Probably unpack the JRE to somewhere.


All the best,
Clemens

On 28 August 2015 at 07:07, Peter Becker <pe...@pe...> wrote:

> One note of warning: unless you compile against a corresponding JDK
> nothing will stop you from picking up a method that won't be in an
> earlier JDK. The result is a NoSuchMethodException (or something like
> that) at runtime.
>
> And there is plenty of innocent looking stuff like this one, which was
> introduced in 1.6:
> http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty()
>
> The only safe ways are to compile against the target JDK or to use
> static code analysis tools.
>

I've not used it but maven animal sniffer plugin will throw exceptions in
case like this.
The documentation is not great, http://stackoverflow.com/a/4451057/552958
should give you enough to get going to enforce this on the minimum jre you
want to run on and allow some comfort on the jdk you want to build against.

One note of warning: unless you compile against a corresponding JDK 
nothing will stop you from picking up a method that won't be in an 
earlier JDK. The result is a NoSuchMethodException (or something like 
that) at runtime.

And there is plenty of innocent looking stuff like this one, which was 
introduced in 1.6: 
http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty()

The only safe ways are to compile against the target JDK or to use 
static code analysis tools.

    Peter


On 27/08/2015 3:10 PM, Clemens Katzer wrote:
>> My java6 choked on "JComboBox<String>", isn't that new in 7?
> Ah, right, that way. But that's only syntactic stuff.
>
> So, correction: No, it can't be compiled with Java 5 or 6, but it can
> be compiled to be runnable on Java 5.
>
> (( the funny thing is, it compiles this code happily with java 7, even
> if -source 1.7 is set (!!!) ))
>
>
> [clemens@myldaptop Colossus]$ grep level build.properties
> source.level=1.5
> target.level=1.5
> [clemens@myldaptop Colossus]$ ant clean jars
> Buildfile: /home/clemens/p/sf/github/coti/Colossus/build.xml
>
> cleanjars:
>      [delete] Deleting:
> /home/clemens/p/sf/github/coti/Colossus/Colossus.jar
>      [delete] Deleting:
> /home/clemens/p/sf/github/coti/Colossus/ColossusWeb.jar
>      [delete] Deleting:
> /home/clemens/p/sf/github/coti/Colossus/CmdlineClient.jar
>
> clean:
>      [delete] Deleting directory
> /home/clemens/p/sf/github/coti/Colossus/build/ant
>
> cleanjars:
>
> clean:
>
> init:
>       [mkdir] Created dir:
> /home/clemens/p/sf/github/coti/Colossus/build/ant/classes
>       [mkdir] Created dir:
> /home/clemens/p/sf/github/coti/Colossus/build/ant/testresults
>
> compile:
>       [javac] Compiling 284 source files to
> /home/clemens/p/sf/github/coti/Colossus/build/ant/classes
>       [javac] warning: [options] bootstrap class path not set in
> conjunction with -source 1.5
>       [javac] 1 warning
>
> compileVariants:
>       [javac] Compiling 17 source files to
> /home/clemens/p/sf/github/coti/Colossus/build/ant/classes
>       [javac] warning: [options] bootstrap class path not set in
> conjunction with -source 1.5
>       [javac] 1 warning
>
> jar:
>         [jar] Building jar:
> /home/clemens/p/sf/github/coti/Colossus/Colossus.jar
>         [jar] Updating jar:
> /home/clemens/p/sf/github/coti/Colossus/Colossus.jar
>         [jar] Updating jar:
> /home/clemens/p/sf/github/coti/Colossus/Colossus.jar
>
> webjar:
>         [jar] Building jar:
> /home/clemens/p/sf/github/coti/Colossus/ColossusWeb.jar
>
> ccj:
>         [jar] Building jar:
> /home/clemens/p/sf/github/coti/Colossus/CmdlineClient.jar
>
> jars:
>
> BUILD SUCCESSFUL
> Total time: 8 seconds
> [clemens@myldaptop Colossus]$ javac -version
> javac 1.7.0_45
> [clemens@myldaptop Colossus]$
>
>
>
> On 2015-08-26 23:04, Romain Dolbeau wrote:
>> 2015-08-26 21:54 GMT+02:00 Clemens Katzer <cle...@cl...
>> [1]>:
>>
>>>> The current code cannot be compiled with java 6 unfortunately.
>>> Actually it can. The build file and the jnlp file say it needs 1.7,
>>> but
>>> there's nothing in the code that won't work with Java 5. As far as
>>> I
>>> know, at least :)
>> My java6 choked on "JComboBox<String>", isn't that new in 7?
>>
>> I haven't done any java in a long time, I could be very wrong.
>>
>> Cordially,
>>
>>   --
>>
>> Romain Dolbeau
>>
>> Links:
>> ------
>> [1] mailto:cle...@cl...
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

2015-08-27 10:52 GMT+02:00 Clemens Katzer <cle...@cl...>:

> Not really, except that I can't test and for example not reproduce any
> user problems on my own computer then.
> ( I am reluctant trying to install Java 1.5 and possibly screw up things
> on my Fedora 21 ).
>

Best effort. As long as it compiles and work for you, target 1.5. If a user
has a problem no-one can reproduce, then the user is on its own :-/


> PS: when will we stop supporting Java 5 then?  When 32 bit systems are
> declared illegally by some state/country and XP does not work on
> 64bit?....;-)
>

When it stops compiling with a 1.5 target :-)

But then, I'm the guy who just checked his Sun 4/330GX from 11/89 was still
running, so my opinion on supporting older systems might be a bit biased :-)

Cordially,

-- 
Romain Dolbeau

On 2015-08-27 10:17, Romain Dolbeau wrote:
> 2015-08-27 7:10 GMT+02:00 Clemens Katzer <cle...@cl...
> [1]>:
>

>
> Any reason not to target 1.5 as it's possible?

Not really, except that I can't test and for example not reproduce any 
user problems on my own computer then.

( I am reluctant trying to install Java 1.5 and possibly screw up 
things on my Fedora 21 ).


> It would enable Colossus on older systems.


Yeah, as I indicated in my previous mail (did I?) I will drop/postpone 
the thought of requiring a newish Java :-/

So.... as usual. When I ask on the list beforehand, it does not matter, 
all say "it's you who decides" but in this case I omitted that 
discussion and it would have been better to ask.....


-Clemens



PS: when will we stop supporting Java 5 then?  When 32 bit systems are 
declared illegally by some state/country and XP does not work on 
64bit?....;-)

> My java6 choked on "JComboBox<String>", isn't that new in 7?

Ah, right, that way. But that's only syntactic stuff.

So, correction: No, it can't be compiled with Java 5 or 6, but it can 
be compiled to be runnable on Java 5.

(( the funny thing is, it compiles this code happily with java 7, even 
if -source 1.7 is set (!!!) ))


[clemens@myldaptop Colossus]$ grep level build.properties
source.level=1.5
target.level=1.5
[clemens@myldaptop Colossus]$ ant clean jars
Buildfile: /home/clemens/p/sf/github/coti/Colossus/build.xml

cleanjars:
    [delete] Deleting: 
/home/clemens/p/sf/github/coti/Colossus/Colossus.jar
    [delete] Deleting: 
/home/clemens/p/sf/github/coti/Colossus/ColossusWeb.jar
    [delete] Deleting: 
/home/clemens/p/sf/github/coti/Colossus/CmdlineClient.jar

clean:
    [delete] Deleting directory 
/home/clemens/p/sf/github/coti/Colossus/build/ant

cleanjars:

clean:

init:
     [mkdir] Created dir: 
/home/clemens/p/sf/github/coti/Colossus/build/ant/classes
     [mkdir] Created dir: 
/home/clemens/p/sf/github/coti/Colossus/build/ant/testresults

compile:
     [javac] Compiling 284 source files to 
/home/clemens/p/sf/github/coti/Colossus/build/ant/classes
     [javac] warning: [options] bootstrap class path not set in 
conjunction with -source 1.5
     [javac] 1 warning

compileVariants:
     [javac] Compiling 17 source files to 
/home/clemens/p/sf/github/coti/Colossus/build/ant/classes
     [javac] warning: [options] bootstrap class path not set in 
conjunction with -source 1.5
     [javac] 1 warning

jar:
       [jar] Building jar: 
/home/clemens/p/sf/github/coti/Colossus/Colossus.jar
       [jar] Updating jar: 
/home/clemens/p/sf/github/coti/Colossus/Colossus.jar
       [jar] Updating jar: 
/home/clemens/p/sf/github/coti/Colossus/Colossus.jar

webjar:
       [jar] Building jar: 
/home/clemens/p/sf/github/coti/Colossus/ColossusWeb.jar

ccj:
       [jar] Building jar: 
/home/clemens/p/sf/github/coti/Colossus/CmdlineClient.jar

jars:

BUILD SUCCESSFUL
Total time: 8 seconds
[clemens@myldaptop Colossus]$ javac -version
javac 1.7.0_45
[clemens@myldaptop Colossus]$



On 2015-08-26 23:04, Romain Dolbeau wrote:
> 2015-08-26 21:54 GMT+02:00 Clemens Katzer <cle...@cl...
> [1]>:
>
>>> The current code cannot be compiled with java 6 unfortunately.
>> Actually it can. The build file and the jnlp file say it needs 1.7,
>> but
>> there's nothing in the code that won't work with Java 5. As far as
>> I
>> know, at least :)
>
> My java6 choked on "JComboBox<String>", isn't that new in 7?
>
> I haven't done any java in a long time, I could be very wrong.
>
> Cordially,
>
>  --
>
> Romain Dolbeau
>
> Links:
> ------
> [1] mailto:cle...@cl...

On 27 August 2015 at 04:24, Romain Dolbeau <ro...@do...> wrote:

>
> 2015-08-26 20:10 GMT+02:00 <sp...@ao...>
>
>>       Your recent Java 7 upgrade makes me unable to play since I do not
>> have anything more than Java 6 on this older computer.  Can you please post
>> the old version using Java 6 on your web site again?
>>
> Colossus is one of the games me and my retired friends have been playing
>> since we were a great deal younger.  If you can't do this, please accept
>> our thanks for ages of delightful playing time.
>>
>>
>
As Romain says, you can always run with an older version... forever more.
But you will be stuck with any bugs that get fixed later.

What systems are you running that dont allow you to install a later version
of Java?