colossus-developers Mailing List for Colossus (Page 5)

FWIW, here's the case where somebody brought it up already while ago:

https://sourceforge.net/p/colossus/bugs/901/


Thx,
Clemens


On 2013-11-12 09:27, Clemens Katzer wrote:
> Hei all,
>
>
> Yes, another user already reported this few weeks ago. He seemed to 
> be
> able to use older versions of Colossus, though. The only difference I
> noticed was that they were signed with a X.509  V1 certificate; all
> modern Java keygens generate V3.
>
> Jeff,
>    could you try out this one here with the new Java that refuses it 
> ?
>
> http://colossus.sourceforge.net/Colossus-old.html
>
>
> If that does not work.... I don't "mind much" to pay for the
> certificate.
>
> In fact I was considering that more than once in the past just to get
> rid of hassle in general. Also, some Game Server user had done a
> significant donation which covers the cert. for several years to
> come.... so that would be a good purpose for that money :>)
>
> It's more the related paperwork holding that back than the money.
>
>
> (As a side note, I consider to change my hosting provider, to have a
> physical server with 4 cores instead of a virtual one [where I have 
> the
> feeling sometimes my virtual one sometimes oes not get CPU for 
> several
> seconds]. Such a server would cost ~60 EUR per month. Instead of the 
> 25
> I pay now. Which is so weak, nowaedays one would get such a virtual
> server for < 10 EUR per months.  It's more the related paperwork ...
> (and having to install a new server from scratch)). So, 69,- per 
> months
> is not worth the time arguing about it. Nowadays my time is so 
> scarce,
> anything that can be solved with money I'll do so....
>
> Having that server would be great also in that sense, that I could
> dedicate one virtual server with 2 cores to run AIs.
>
>
>
> BR,
> Clemens
>
>
>
> On 2013-11-12 05:58, Barrie Treloar wrote:
>> On 12 November 2013 13:29, Jeff Matthews <je...@xe...> wrote:
>>> Are you talking about an SSL?  If so, Godaddy is advertising them
>>> for
>>> $69/year.
>>
>> But even $69 dollars a year - are you going to pay?
>> This is open source hobby stuff.
>>
>> You need a code signing certificate.
>> See http://stackoverflow.com/a/1906679
>> I've included the list of included root ca's at the end of this
>> email,
>> it lists godaddyclass2ca as a trusted cert.
>>
>> This is linked with my previous answer that the root certificate
>> needs
>> to be trusted by Java in the cacerts file.
>> At work we tinker with that as part of the SOE build so that our
>> internal root CA is trusted so we can use self-signed certificates
>> for
>> internal SSL connections in Java.
>> The same principle will work with the self-signed root certificate
>> that Clemens has created, its just the manual steps non-power users
>> would have to go through would be confusing, frightening, or 
>> avoided,
>> but there may be no other alternatives.
>>
>> === Java Trusts Root CAs (from Java 7u7 on Windows) ===
>> addtrustclass1ca
>> addtrustexternalca
>> addtrustqualifiedca
>> aolrootca1
>> aolrootca2
>> baltimorecodesigningca
>> baltimorecybertrustca
>> camerfirmachambersca
>> camerfirmachamberscommerceca
>> camerfirmachambersignca
>> certplusclass2primaryca
>> certplusclass3pprimaryca
>> certumca
>> certumtrustednetworkca
>> comodoaaaca
>> deutschetelekomrootca2
>> digicertassuredidrootca
>> digicertglobalrootca
>> digicerthighassuranceevrootca
>> entrust2048ca
>> entrustevca
>> entrustsslca
>> equifaxsecureca
>> equifaxsecureebusinessca1
>> equifaxsecureebusinessca2
>> equifaxsecureglobalebusinessca1
>> geotrustglobalca
>> globalsignca
>> globalsignr2ca
>> globalsignr3ca
>> godaddyclass2ca
>> gtecybertrust5ca
>> gtecybertrustglobalca
>> keynectisrootca
>> quovadisrootca
>> quovadisrootca2
>> quovadisrootca3
>> secomevrootca1
>> secomscrootca1
>> secomscrootca2
>> secomvalicertclass1ca
>> soneraclass1ca
>> soneraclass2ca
>> starfieldclass2ca
>> swisssigngoldg2ca
>> swisssignplatinumg2ca
>> swisssignsilverg2ca
>> thawtepersonalbasicca
>> thawtepersonalfreemailca
>> thawtepersonalpremiumca
>> thawtepremiumserverca
>> thawteserverca
>> trustcenterclass2caii
>> trustcenterclass4caii
>> trustcenteruniversalcai
>> ttelesecglobalrootclass2ca
>> ttelesecglobalrootclass3ca
>> utndatacorpsgcca
>> utnuserfirstclientauthemailca
>> utnuserfirsthardwareca
>> utnuserfirstobjectca
>> valicertclass2ca
>> verisignclass1ca
>> verisignclass1g2ca
>> verisignclass1g3ca
>> verisignclass2ca
>> verisignclass2g2ca
>> verisignclass2g3ca
>> verisignclass3ca
>> verisignclass3g2ca
>> verisignclass3g3ca
>> verisignserverca
>> verisigntsaca
>>
>>
>> 
>> ------------------------------------------------------------------------------
>> November Webinars for C, C++, Fortran Developers
>> Accelerate application performance with scalable programming models.
>> Explore
>> techniques for threading, error checking, porting, and tuning. Get
>> the most
>> from the latest Intel processors and coprocessors. See abstracts and
>> register
>>
>> 
>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Colossus-developers mailing list
>> Col...@li...
>> https://lists.sourceforge.net/lists/listinfo/colossus-developers
>
>
> 
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. 
> Explore
> techniques for threading, error checking, porting, and tuning. Get 
> the most
> from the latest Intel processors and coprocessors. See abstracts and 
> register
> 
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

> The CA just signs the public key.

of course. But roughly looking over it, I didn't see any "send it to 
them and they sign it" step.

BR,
Clemens


On 2013-11-12 16:09, Bruno Wolff III wrote:
> On Tue, Nov 12, 2013 at 14:07:23 +0200,
>   Clemens Katzer <cle...@cl...> wrote:
>>
>>I can't imagine that any CA for which users can create their own key
>>with,
>>will be included ( = out of the box delivered in)  somewhere (be it
>>browser or java).
>
> You should always be creating your own key pair. The CA just signs
> the public key. They don't need to (and shouldn't) see your private
> key.

On Tue, Nov 12, 2013 at 14:07:23 +0200,
   Clemens Katzer <cle...@cl...> wrote:
>
>I can't imagine that any CA for which users can create their own key
>with,
>will be included ( = out of the box delivered in)  somewhere (be it
>browser or java).

You should always be creating your own key pair. The CA just signs the 
public key. They don't need to (and shouldn't) see your private key.

On Mon, Nov 11, 2013 at 22:06:41 -0600,
   Jeff Matthews <je...@xe...> wrote:
>I would volunteer to pay it for a year if there's no easy work-around.

Once you pay Danegeld you never get rid of the Dane.

> It has to be supported by Java (not the browser).

My understanding was, that one needs to have the CA cert installed in 
the browser,
then webstart can verify the given cert agains that CA root authority.


I don't get the point how this StartSSL is supposed to work. With that 
approach,
you basically do self-sign the certificate anyway.

I can't imagine that any CA for which users can create their own key 
with,
will be included ( = out of the box delivered in)  somewhere (be it 
browser or java).

BR,
Clemens



On 2013-11-12 13:53, Barrie Treloar wrote:
> On 12 November 2013 19:41, Clemens Katzer <cle...@cl...> 
> wrote:
>>
>>> Second, free SSL certificates are now available.  I know 
>>> startssl.com
>>> has them.
>>
>> How well is that root certificate supported ( = by default installed 
>> )
>> by recent browsers?
>
> It has to be supported by Java (not the browser).
>
> They dont appear to be in the list I posted.
> This page https://forum.startcom.org/viewtopic.php?t=1390 gives
> instructions on how to install a StartCom (previous company name?)
> certificate into keytool.
> If you have to do that you might as well generate your own root
> certificate...
>
> 
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. 
> Explore
> techniques for threading, error checking, porting, and tuning. Get 
> the most
> from the latest Intel processors and coprocessors. See abstracts and 
> register
> 
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

On 12 November 2013 19:41, Clemens Katzer <cle...@cl...> wrote:
>
>> Second, free SSL certificates are now available.  I know startssl.com
>> has them.
>
> How well is that root certificate supported ( = by default installed )
> by recent browsers?

It has to be supported by Java (not the browser).

They dont appear to be in the list I posted.
This page https://forum.startcom.org/viewtopic.php?t=1390 gives
instructions on how to install a StartCom (previous company name?)
certificate into keytool.
If you have to do that you might as well generate your own root certificate...

> Second, free SSL certificates are now available.  I know startssl.com
> has them.

How well is that root certificate supported ( = by default installed ) 
by recent browsers?

That has been typically the handicap with the free ones.


BR,
Clemens



On 2013-11-12 10:03, David Ripton wrote:
> On 11/11/2013 09:52 PM, Barrie Treloar wrote:
>> Ok, being behind a firewall confuses Java WebStart.
>> After futzing around I was able to reproduce your dialog and click
>> through on the more information links which leads to
>> http://java.com/en/download/help/appsecuritydialogs.xml#selfsigned
>> And there is some stuff here http://webstartfaq.com/#47 about the
>> security dialog.
>>
>> I think for now ignore that fact that Java is telling you it will 
>> stop
>> working in the future.
>> We will worry about it then.
>> Damn, googling has found Java 7u51 (Jan 2014) will cause this 
>> problem,
>> see
>> 
>> https://blogs.oracle.com/java-platform-group/entry/new_security_requirements_for_rias
>>
>> There appears to be no links to help people who use self signed
>> certificates.
>> Why should we pay $200+ for a certificate, every few years.
>
> First, this new security requirement is only for Java Web Start, the 
> way
> to run the game with one click on the web page.  (Also for Applets 
> but
> we don't use those.)  If you manually download and install Colossus 
> then
> it will still work.  So, not quite as easy, but still playable.
> (Colossus existed for several years before JWS did, and we had plenty 
> of
> players.  It was a tech support burden to constantly walk users 
> through
> installing Java, though.)
>
> Second, free SSL certificates are now available.  I know startssl.com
> has them.  I suspect it's not that hard to download and setup a free
> cert to make the game "trusted," though I haven't actually done it.
>
>> One option would be to put the root certificate's public stuff up on
>> Colossus and explaining how to add that your local key store.
>> This is stuff that is beyond the typical person who just wants to 
>> play a
>> game and a pain in the ass.
>> Its not terrible hard but having to maintain documentation across
>> multiple platforms is not something to enjoy.
>>
>> Time to move to slug-a-thon ? :)
>
> Slugathon is still harder to install than Colossus, so I don't 
> recommend
> switching to get an easier install experience.

On 11/11/2013 09:52 PM, Barrie Treloar wrote:
> Ok, being behind a firewall confuses Java WebStart.
> After futzing around I was able to reproduce your dialog and click
> through on the more information links which leads to
> http://java.com/en/download/help/appsecuritydialogs.xml#selfsigned
> And there is some stuff here http://webstartfaq.com/#47 about the
> security dialog.
>
> I think for now ignore that fact that Java is telling you it will stop
> working in the future.
> We will worry about it then.
> Damn, googling has found Java 7u51 (Jan 2014) will cause this problem,
> see
> https://blogs.oracle.com/java-platform-group/entry/new_security_requirements_for_rias
>
> There appears to be no links to help people who use self signed
> certificates.
> Why should we pay $200+ for a certificate, every few years.

First, this new security requirement is only for Java Web Start, the way 
to run the game with one click on the web page.  (Also for Applets but 
we don't use those.)  If you manually download and install Colossus then 
it will still work.  So, not quite as easy, but still playable. 
(Colossus existed for several years before JWS did, and we had plenty of 
players.  It was a tech support burden to constantly walk users through 
installing Java, though.)

Second, free SSL certificates are now available.  I know startssl.com 
has them.  I suspect it's not that hard to download and setup a free 
cert to make the game "trusted," though I haven't actually done it.

> One option would be to put the root certificate's public stuff up on
> Colossus and explaining how to add that your local key store.
> This is stuff that is beyond the typical person who just wants to play a
> game and a pain in the ass.
> Its not terrible hard but having to maintain documentation across
> multiple platforms is not something to enjoy.
>
> Time to move to slug-a-thon ? :)

Slugathon is still harder to install than Colossus, so I don't recommend 
switching to get an easier install experience.

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

Hei all,


Yes, another user already reported this few weeks ago. He seemed to be 
able to use older versions of Colossus, though. The only difference I 
noticed was that they were signed with a X.509  V1 certificate; all 
modern Java keygens generate V3.

Jeff,
   could you try out this one here with the new Java that refuses it ?

http://colossus.sourceforge.net/Colossus-old.html


If that does not work.... I don't "mind much" to pay for the 
certificate.

In fact I was considering that more than once in the past just to get 
rid of hassle in general. Also, some Game Server user had done a 
significant donation which covers the cert. for several years to 
come.... so that would be a good purpose for that money :>)

It's more the related paperwork holding that back than the money.


(As a side note, I consider to change my hosting provider, to have a 
physical server with 4 cores instead of a virtual one [where I have the 
feeling sometimes my virtual one sometimes oes not get CPU for several 
seconds]. Such a server would cost ~60 EUR per month. Instead of the 25 
I pay now. Which is so weak, nowaedays one would get such a virtual 
server for < 10 EUR per months.  It's more the related paperwork ... 
(and having to install a new server from scratch)). So, 69,- per months 
is not worth the time arguing about it. Nowadays my time is so scarce, 
anything that can be solved with money I'll do so....

Having that server would be great also in that sense, that I could 
dedicate one virtual server with 2 cores to run AIs.



BR,
Clemens



On 2013-11-12 05:58, Barrie Treloar wrote:
> On 12 November 2013 13:29, Jeff Matthews <je...@xe...> wrote:
>> Are you talking about an SSL?  If so, Godaddy is advertising them 
>> for
>> $69/year.
>
> But even $69 dollars a year - are you going to pay?
> This is open source hobby stuff.
>
> You need a code signing certificate.
> See http://stackoverflow.com/a/1906679
> I've included the list of included root ca's at the end of this 
> email,
> it lists godaddyclass2ca as a trusted cert.
>
> This is linked with my previous answer that the root certificate 
> needs
> to be trusted by Java in the cacerts file.
> At work we tinker with that as part of the SOE build so that our
> internal root CA is trusted so we can use self-signed certificates 
> for
> internal SSL connections in Java.
> The same principle will work with the self-signed root certificate
> that Clemens has created, its just the manual steps non-power users
> would have to go through would be confusing, frightening, or avoided,
> but there may be no other alternatives.
>
> === Java Trusts Root CAs (from Java 7u7 on Windows) ===
> addtrustclass1ca
> addtrustexternalca
> addtrustqualifiedca
> aolrootca1
> aolrootca2
> baltimorecodesigningca
> baltimorecybertrustca
> camerfirmachambersca
> camerfirmachamberscommerceca
> camerfirmachambersignca
> certplusclass2primaryca
> certplusclass3pprimaryca
> certumca
> certumtrustednetworkca
> comodoaaaca
> deutschetelekomrootca2
> digicertassuredidrootca
> digicertglobalrootca
> digicerthighassuranceevrootca
> entrust2048ca
> entrustevca
> entrustsslca
> equifaxsecureca
> equifaxsecureebusinessca1
> equifaxsecureebusinessca2
> equifaxsecureglobalebusinessca1
> geotrustglobalca
> globalsignca
> globalsignr2ca
> globalsignr3ca
> godaddyclass2ca
> gtecybertrust5ca
> gtecybertrustglobalca
> keynectisrootca
> quovadisrootca
> quovadisrootca2
> quovadisrootca3
> secomevrootca1
> secomscrootca1
> secomscrootca2
> secomvalicertclass1ca
> soneraclass1ca
> soneraclass2ca
> starfieldclass2ca
> swisssigngoldg2ca
> swisssignplatinumg2ca
> swisssignsilverg2ca
> thawtepersonalbasicca
> thawtepersonalfreemailca
> thawtepersonalpremiumca
> thawtepremiumserverca
> thawteserverca
> trustcenterclass2caii
> trustcenterclass4caii
> trustcenteruniversalcai
> ttelesecglobalrootclass2ca
> ttelesecglobalrootclass3ca
> utndatacorpsgcca
> utnuserfirstclientauthemailca
> utnuserfirsthardwareca
> utnuserfirstobjectca
> valicertclass2ca
> verisignclass1ca
> verisignclass1g2ca
> verisignclass1g3ca
> verisignclass2ca
> verisignclass2g2ca
> verisignclass2g3ca
> verisignclass3ca
> verisignclass3g2ca
> verisignclass3g3ca
> verisignserverca
> verisigntsaca
>
> 
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. 
> Explore
> techniques for threading, error checking, porting, and tuning. Get 
> the most
> from the latest Intel processors and coprocessors. See abstracts and 
> register
> 
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

I would volunteer to pay it for a year if there's no easy work-around.

Jeff Matthews
MATTHEWS | EASLEY | CHANEY
13430 Northwest Freeway, Suite 990
Houston, Texas 77040
Ph. (713) 223-4000
Fax (281) 589-9000



-----Original Message-----
From: Barrie Treloar [mailto:bae...@gm...] 
Sent: Monday, November 11, 2013 9:58 PM
To: Jeff Matthews
Cc: Colossus dev list
Subject: Re: [Colossus-developers] checkin mails to colossus-dev

On 12 November 2013 13:29, Jeff Matthews <je...@xe...> wrote:
> Are you talking about an SSL?  If so, Godaddy is advertising them for 
> $69/year.

But even $69 dollars a year - are you going to pay?
This is open source hobby stuff.

You need a code signing certificate.
See http://stackoverflow.com/a/1906679
I've included the list of included root ca's at the end of this email, it
lists godaddyclass2ca as a trusted cert.

This is linked with my previous answer that the root certificate needs to be
trusted by Java in the cacerts file.
At work we tinker with that as part of the SOE build so that our internal
root CA is trusted so we can use self-signed certificates for internal SSL
connections in Java.
The same principle will work with the self-signed root certificate that
Clemens has created, its just the manual steps non-power users would have to
go through would be confusing, frightening, or avoided, but there may be no
other alternatives.

=== Java Trusts Root CAs (from Java 7u7 on Windows) === addtrustclass1ca
addtrustexternalca addtrustqualifiedca
aolrootca1
aolrootca2
baltimorecodesigningca
baltimorecybertrustca
camerfirmachambersca
camerfirmachamberscommerceca
camerfirmachambersignca
certplusclass2primaryca
certplusclass3pprimaryca
certumca
certumtrustednetworkca
comodoaaaca
deutschetelekomrootca2
digicertassuredidrootca
digicertglobalrootca
digicerthighassuranceevrootca
entrust2048ca
entrustevca
entrustsslca
equifaxsecureca
equifaxsecureebusinessca1
equifaxsecureebusinessca2
equifaxsecureglobalebusinessca1
geotrustglobalca
globalsignca
globalsignr2ca
globalsignr3ca
godaddyclass2ca
gtecybertrust5ca
gtecybertrustglobalca
keynectisrootca
quovadisrootca
quovadisrootca2
quovadisrootca3
secomevrootca1
secomscrootca1
secomscrootca2
secomvalicertclass1ca
soneraclass1ca
soneraclass2ca
starfieldclass2ca
swisssigngoldg2ca
swisssignplatinumg2ca
swisssignsilverg2ca
thawtepersonalbasicca
thawtepersonalfreemailca
thawtepersonalpremiumca
thawtepremiumserverca
thawteserverca
trustcenterclass2caii
trustcenterclass4caii
trustcenteruniversalcai
ttelesecglobalrootclass2ca
ttelesecglobalrootclass3ca
utndatacorpsgcca
utnuserfirstclientauthemailca
utnuserfirsthardwareca
utnuserfirstobjectca
valicertclass2ca
verisignclass1ca
verisignclass1g2ca
verisignclass1g3ca
verisignclass2ca
verisignclass2g2ca
verisignclass2g3ca
verisignclass3ca
verisignclass3g2ca
verisignclass3g3ca
verisignserverca
verisigntsaca

On 12 November 2013 13:29, Jeff Matthews <je...@xe...> wrote:
> Are you talking about an SSL?  If so, Godaddy is advertising them for
> $69/year.

But even $69 dollars a year - are you going to pay?
This is open source hobby stuff.

You need a code signing certificate.
See http://stackoverflow.com/a/1906679
I've included the list of included root ca's at the end of this email,
it lists godaddyclass2ca as a trusted cert.

This is linked with my previous answer that the root certificate needs
to be trusted by Java in the cacerts file.
At work we tinker with that as part of the SOE build so that our
internal root CA is trusted so we can use self-signed certificates for
internal SSL connections in Java.
The same principle will work with the self-signed root certificate
that Clemens has created, its just the manual steps non-power users
would have to go through would be confusing, frightening, or avoided,
but there may be no other alternatives.

=== Java Trusts Root CAs (from Java 7u7 on Windows) ===
addtrustclass1ca
addtrustexternalca
addtrustqualifiedca
aolrootca1
aolrootca2
baltimorecodesigningca
baltimorecybertrustca
camerfirmachambersca
camerfirmachamberscommerceca
camerfirmachambersignca
certplusclass2primaryca
certplusclass3pprimaryca
certumca
certumtrustednetworkca
comodoaaaca
deutschetelekomrootca2
digicertassuredidrootca
digicertglobalrootca
digicerthighassuranceevrootca
entrust2048ca
entrustevca
entrustsslca
equifaxsecureca
equifaxsecureebusinessca1
equifaxsecureebusinessca2
equifaxsecureglobalebusinessca1
geotrustglobalca
globalsignca
globalsignr2ca
globalsignr3ca
godaddyclass2ca
gtecybertrust5ca
gtecybertrustglobalca
keynectisrootca
quovadisrootca
quovadisrootca2
quovadisrootca3
secomevrootca1
secomscrootca1
secomscrootca2
secomvalicertclass1ca
soneraclass1ca
soneraclass2ca
starfieldclass2ca
swisssigngoldg2ca
swisssignplatinumg2ca
swisssignsilverg2ca
thawtepersonalbasicca
thawtepersonalfreemailca
thawtepersonalpremiumca
thawtepremiumserverca
thawteserverca
trustcenterclass2caii
trustcenterclass4caii
trustcenteruniversalcai
ttelesecglobalrootclass2ca
ttelesecglobalrootclass3ca
utndatacorpsgcca
utnuserfirstclientauthemailca
utnuserfirsthardwareca
utnuserfirstobjectca
valicertclass2ca
verisignclass1ca
verisignclass1g2ca
verisignclass1g3ca
verisignclass2ca
verisignclass2g2ca
verisignclass2g3ca
verisignclass3ca
verisignclass3g2ca
verisignclass3g3ca
verisignserverca
verisigntsaca

Are you talking about an SSL?  If so, Godaddy is advertising them for
$69/year.

 

Jeff Matthews

MATTHEWS | EASLEY | CHANEY

13430 Northwest Freeway, Suite 990

Houston, Texas 77040

Ph. (713) 223-4000

Fax (281) 589-9000

 

 

From: Barrie Treloar [mailto:bae...@gm...] 
Sent: Monday, November 11, 2013 8:52 PM
To: Jeff Matthews
Cc: Colossus dev list
Subject: Re: [Colossus-developers] checkin mails to colossus-dev

 

Ok, being behind a firewall confuses Java WebStart.

After futzing around I was able to reproduce your dialog and click through
on the more information links which leads to
http://java.com/en/download/help/appsecuritydialogs.xml#selfsigned

And there is some stuff here http://webstartfaq.com/#47 about the security
dialog.

I think for now ignore that fact that Java is telling you it will stop
working in the future.
We will worry about it then.
Damn, googling has found Java 7u51 (Jan 2014) will cause this problem, see
https://blogs.oracle.com/java-platform-group/entry/new_security_requirements
_for_rias

There appears to be no links to help people who use self signed
certificates.
Why should we pay $200+ for a certificate, every few years.

 

One option would be to put the root certificate's public stuff up on
Colossus and explaining how to add that your local key store.

This is stuff that is beyond the typical person who just wants to play a
game and a pain in the ass.

Its not terrible hard but having to maintain documentation across multiple
platforms is not something to enjoy.

 

Time to move to slug-a-thon ? :)

 

Ok, being behind a firewall confuses Java WebStart.
After futzing around I was able to reproduce your dialog and click through
on the more information links which leads to
http://java.com/en/download/help/appsecuritydialogs.xml#selfsigned
And there is some stuff here http://webstartfaq.com/#47 about the security
dialog.

I think for now ignore that fact that Java is telling you it will stop
working in the future.
We will worry about it then.
Damn, googling has found Java 7u51 (Jan 2014) will cause this problem, see
https://blogs.oracle.com/java-platform-group/entry/new_security_requirements_for_rias

There appears to be no links to help people who use self signed
certificates.
Why should we pay $200+ for a certificate, every few years.

One option would be to put the root certificate's public stuff up on
Colossus and explaining how to add that your local key store.
This is stuff that is beyond the typical person who just wants to play a
game and a pain in the ass.
Its not terrible hard but having to maintain documentation across multiple
platforms is not something to enjoy.

Time to move to slug-a-thon ? :)

On 12 November 2013 10:51, Jeff Matthews <je...@xe...> wrote:
> Hi, all.  Don't know if this is in the current discussion, but my latest
> Java update says apps by Unknown Publishers will be blocked in the next
> release because they are clamping down to try to tighten-up security.

Can you provide a link?

What do you mean by apps?
Colossus can run standalone or via web-start.
I'd be amazed if standalone apps required a certificate.

Hi, all.  Don't know if this is in the current discussion, but my latest
Java update says apps by Unknown Publishers will be blocked in the next
release because they are clamping down to try to tighten-up security.   

Jeff Matthews
MATTHEWS | EASLEY | CHANEY
13430 Northwest Freeway, Suite 990
Houston, Texas 77040
Ph. (713) 223-4000
Fax (281) 589-9000


-----Original Message-----
From: Clemens Katzer [mailto:cle...@cl...] 
Sent: Saturday, October 19, 2013 2:49 AM
To: col...@li...
Subject: Re: [Colossus-developers] checkin mails to colossus-dev

I didn't do anything. It started when they migrated Colossus to the "new SF"
version.

Is the new one (with [colossus:code] in subject, that's the summary,
right?) sent to developers-list? I see both as sender and recipient some
no-reply address.

But that one should be easy to get rid of, there's a unsubscribe link at the
bottom. I don't think it causes more spam in this case :)

BR,
Clemens



On 2013-10-19 01:32, David Ripton wrote:
> In the last few days, I've started to see summary checkin messages 
> sent to colossus-developers, in addition to full diffs sent to 
> colossus-checkins where they've gone for years.
>
> Clemens, did you change something on purpose, or is this something SF 
> did?
>
> (It doesn't *really* matter; we don't usually have that many checkins 
> and it's not that hard to filter them out.  I just find it mildly 
> annoying because we already have a separate list for them.)


----------------------------------------------------------------------------
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
from the latest Intel processors and coprocessors. See abstracts and
register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
_______________________________________________
Colossus-developers mailing list
Col...@li...
https://lists.sourceforge.net/lists/listinfo/colossus-developers

I didn't do anything. It started when they migrated Colossus to the 
"new SF" version.

Is the new one (with [colossus:code] in subject, that's the summary, 
right?) sent to developers-list? I see both as sender and recipient some 
no-reply address.

But that one should be easy to get rid of, there's a unsubscribe link 
at the bottom. I don't think it causes more spam in this case :)

BR,
Clemens



On 2013-10-19 01:32, David Ripton wrote:
> In the last few days, I've started to see summary checkin messages 
> sent
> to colossus-developers, in addition to full diffs sent to
> colossus-checkins where they've gone for years.
>
> Clemens, did you change something on purpose, or is this something SF 
> did?
>
> (It doesn't *really* matter; we don't usually have that many checkins
> and it's not that hard to filter them out.  I just find it mildly
> annoying because we already have a separate list for them.)

In the last few days, I've started to see summary checkin messages sent 
to colossus-developers, in addition to full diffs sent to 
colossus-checkins where they've gone for years.

Clemens, did you change something on purpose, or is this something SF did?

(It doesn't *really* matter; we don't usually have that many checkins 
and it's not that hard to filter them out.  I just find it mildly 
annoying because we already have a separate list for them.)

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

Hi all,

it seems one can not change the level of logging when Colossus is 
started via web start?

Story:

I had modified the log level of some messages to FINE/FINER and 
adjusted logging.properties for those 3 classes. Running that locally 
they appear to log window, all right.

But when I uploaded the jar to the web site, starting it via web start 
only INFO messages are logged.
Looking closely, indeed the logging.properties isn't even included in 
the jar file! And even if it were, I am sceptic whether the application 
would use it, since there's nothing in the JNLP file telling it to do so 
(in contrast to starting from cmdline, where it's given with -D 
argument).

Didn't find much in google which "helped me right away".

As result, to have the web start "special build" give the user those 
log messages, I have changed them now in the code to INFO.  :-/

Any ideas?

Thx,
Clemens

Hello world,

the build behind the "special build" icon is now "0.14.0special3".

Changes are only related to logging, in particular for the "Battle 
hangs" issue.

In detail:

- log messages are stored to log window no matter whether it's opened 
or not
- closing the window with the "x" in it's frame they are wiped out;
- hiding it only via the menu bar they stay there

- adjusted the level of quite a number of log messages, especially:
- in ClientGUI, ClientThread and SocketClientThread set the level INFO 
for those log messages which might be helpful to get a better clue about 
this "battle hangs up the game" problem.


All the best,
Clemens



On 2013-10-12 13:36, Clemens Katzer wrote:
> Hi there,
>
> I have made a special version:
>
> 
> http://colossus.sourceforge.net/special-build/Colossus-special-build.jnlp
>
> It does a lot of logging: Almost every method in ClientGUI tells that
> it's called ("CG: ..."), and when ClientThread is taking a message 
> from
> the queue while it's FIGHT phase (Masterboard) it tells that too (not
> the arguments, though, didn't get it working quickly), those appear 
> as
> "CT, message ....".
>
> The built-in log window does not autoscroll always to end, though.
>
> So, if you could give it a try? Perhaps also some other players that
> experience that getting stuck (being the one that does get stuck)
> repeatedly could try.
>
>
> Thx,
> Clemens
>
>
>
>
> Below is an example output, starting where a Masterboard Move phase
> ended.
> (You won't see the "Message from ..." in your log, they are not in 
> the
> client,
> but when I run locally of course all is in same JVM).
>
>
> Message from 'SCT-Red' to server:doneWithMoves
> Phase advances to Fight
> Message from 'SCT-Other' to server:confirmCommitPoint ~ 93
> CG: actOnSetupFight()
> CG: clearUndoStack()
> CG: updateStatusScreen()
> CG: setupPlayerLabel()
> Message from 'SCT-Red' to server:confirmCommitPoint ~ 93
> CT, message: nextEngagement()
> CT, message: kickPhase()
> Message from 'SCT-Red' to server:engage ~ 115
> CT, message: kickPhase()
> A new engagement: Plains hex 115 attacker Rd11 defender Or06
> CT, message: tellEngagement()
> A new engagement: Plains hex 115 attacker Rd11 defender Or06
> CG: tellEngagement(Legion attacker, Legion defender, int turnNumber)
> CG: defaultCursor()
> CT, message: tellEngagement()
> A new engagement: Plains hex 115 attacker Rd11 defender Or06
> CT, message: revealCreatures()
> CT, message: revealCreatures()
> CT, message: askConcede()
> Message from 'SCT-Red' to server:doNotConcede ~ Rd11
> CT, message: askNegotiate()
> Message from 'SCT-Other' to server:makeProposal ~ true %@% false %@%
> Rd11 %@% Or06 %@% null %@%
> CT, message: askNegotiate()
> Message from 'SCT-Red' to server:makeProposal ~ true %@% false %@% 
> Rd11
> %@% Or06 %@% null %@%
> CT, message: revealEngagedCreatures()
> CG: revealEngagedCreatures(Legion legion,
> CT, message: revealEngagedCreatures()
> CT, message: revealEngagedCreatures()
> CG: revealEngagedCreatures(Legion legion,
> CT, message: revealEngagedCreatures()
> Rd11 (Red) attacks Or06 (Other) in Plains hex 115
> CT, message: initBattle()
> CG: cleanupNegotiationDialogs()
> Battle client side instantiated for Rd11 attacking Or06 in land 
> Plains
> CG: actOnInitBattle()
> CG: ensureEdtNewBattleBoard()
> CG: doNewBattleBoard()
> CT, message: initBattle()
> Battle client side instantiated for Rd11 attacking Or06 in land 
> Plains
> CT, message: placeNewChit()
> CT, message: placeNewChit()
> CT, message: placeNewChit()
> CT, message: placeNewChit()
> CG: actOnPlaceNewChit(String imageName, BattleUnit battleUnit,
> CT, message: placeNewChit()
> CG: addBattleChit(GUIBattleChit battleChit)
> CT, message: placeNewChit()
> CT, message: placeNewChit()
> CG: actOnPlaceNewChit(String imageName, BattleUnit battleUnit,
> CT, message: placeNewChit()
> CG: addBattleChit(GUIBattleChit battleChit)
> CT, message: placeNewChit()
> CG: actOnPlaceNewChit(String imageName, BattleUnit battleUnit,
> CT, message: placeNewChit()
> CG: addBattleChit(GUIBattleChit battleChit)
> CT, message: placeNewChit()
> CG: actOnPlaceNewChit(String imageName, BattleUnit battleUnit,
> CG: addBattleChit(GUIBattleChit battleChit)
> CT, message: placeNewChit()
> CG: actOnPlaceNewChit(String imageName, BattleUnit battleUnit,
> CT, message: placeNewChit()
> CG: addBattleChit(GUIBattleChit battleChit)
> CT, message: placeNewChit()
> CT, message: placeNewChit()
> CG: actOnPlaceNewChit(String imageName, BattleUnit battleUnit,
> CG: addBattleChit(GUIBattleChit battleChit)
> CT, message: placeNewChit()
> CG: actOnPlaceNewChit(String imageName, BattleUnit battleUnit,
> CG: addBattleChit(GUIBattleChit battleChit)
> CT, message: placeNewChit()
> CG: actOnPlaceNewChit(String imageName, BattleUnit battleUnit,
> CG: addBattleChit(GUIBattleChit battleChit)
> CT, message: placeNewChit()
> CG: actOnPlaceNewChit(String imageName, BattleUnit battleUnit,
> CT, message: placeNewChit()
> CT, message: placeNewChit()
> CG: addBattleChit(GUIBattleChit battleChit)
> CT, message: placeNewChit()
> CG: actOnPlaceNewChit(String imageName, BattleUnit battleUnit,
> CT, message: placeNewChit()
> CG: addBattleChit(GUIBattleChit battleChit)
> CT, message: placeNewChit()
> CT, message: placeNewChit()
> CG: actOnPlaceNewChit(String imageName, BattleUnit battleUnit,
> CG: addBattleChit(GUIBattleChit battleChit)
> CT, message: placeNewChit()
> ...
> ...
> ...
>
>
>
>
> On 2013-10-11 20:19, Jeff Matthews wrote:
>> Will do.
>>
>> Jeff Matthews
>> MATTHEWS | EASLEY | CHANEY
>> 13430 Northwest Freeway, Suite 990
>> Houston, Texas 77040
>> Ph. (713) 223-4000
>> Fax (281) 589-9000
>>
>>
>>
>> -----Original Message-----
>> From: Clemens Katzer [mailto:cle...@cl...]
>> Sent: Friday, October 11, 2013 12:18 PM
>> To: Jeff Matthews
>> Cc: col...@li...
>> Subject: RE: [Colossus-developers] Battle Hangs
>>
>>
>>
>>> I set up my pieces on
>>> battleboard.  Opponent was waiting for me to be "done," but I was
>>> done.  So,
>>
>> But this is when both have the board already up. By then we are far
>> past the scenario I described.
>>
>> I thought the problem manifests like that that one player does not
>> even get his board displayed?
>>
>> So, it can be both ways: that the defender can not do the initial
>> placing, or that the attacker does not get signalled "defender's
>> done,
>> now it's your turn to place your pieces".
>>
>> Would be very good to get last 50 lines or so from log in that
>> moment.
>> Especially the one who does not get to do that what he would be
>> supposed to.
>>
>>
>>> but my opponent could not set up his pieces.  So, he conceded the
>>> game.
>>
>> So he had the battleboard, but no creatures clickable ?
>> Not even shown?
>>
>> Pay attention to details next time. Like, when it's ones turn to set
>> up
>> pieces, the box (top row) indicating the battle turn is red framed,
>> same
>> the marker beside the creatures. This signals, that the client has
>> got
>> from server the request to set up things so that player can start 
>> his
>> placing.
>>
>> If board comes up but this "box and marker red" is not there, the
>> possibilities where it can go wrong would be narrowed down quite
>> much.
>>
>>
>> _Clemens
>>
>>
>>
>>
>> On 2013-10-11 20:07, Jeff Matthews wrote:
>>>> A person is able to maintain the game progress by conceding the
>>>> battle.
>>> (the attacker? the one who gots stuck? Or is/can/must it be 
>>> conceded
>>> by the
>>> one who'se board DID come up?
>>>
>>> (How would the one who got stuck concede - if there's no battle
>>> board??
>>> Does the Masterboard concede help? Would be strange, since that one
>>> is meant
>>> to signal "I concede whole game". But it's fully possible that
>>> there's only
>>> one message called concede and server handled it differently
>>> depending on
>>> game state.  As we know, Colossus mostly works, not because it was
>>> so
>>> perfectly designed, but because not working things were eliminated
>>> one by
>>> one....)
>>>
>>> Ok.  This might help.  Last night, I was attacked.  I set up my
>>> pieces on
>>> battleboard.  Opponent was waiting for me to be "done," but I was
>>> done.  So,
>>> he conceded the battle, and the game played on.  The same thing
>>> happened a
>>> second time.  Here's a twist to the first 2:  The 3rd incident, I
>>> was
>>> the
>>> attacker, but my opponent could not set up his pieces.  So, he
>>> conceded the
>>> game.
>>>
>>> So, it looks as if it works both ways.
>>>
>>> I will look to display the log window while playing and note
>>> messages
>>> next
>>> time it hangs.
>>>
>>> BTW, we often do start clicking all sorts of things, including the
>>> legion on
>>> the masterboard (at least, I do), and so it is interesting about
>>> your
>>> comments concerning possible multiple process requests.
>>>
>>>
>>> Jeff Matthews
>>> MATTHEWS | EASLEY | CHANEY
>>> 13430 Northwest Freeway, Suite 990
>>> Houston, Texas 77040
>>> Ph. (713) 223-4000
>>> Fax (281) 589-9000
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Clemens Katzer [mailto:cle...@cl...]
>>> Sent: Friday, October 11, 2013 11:58 AM
>>> To: col...@li...
>>> Subject: Re: [Colossus-developers] Battle Hangs
>>>
>>>
>>>
>>>>>>>>> Yeah. I was going to try to modify the code to make some 
>>>>>>>>> logs,
>>>> but I soon learned I was too much of a novice.
>>>
>>> I don't think it needs much extra logs. If the EDT does not freeze,
>>> this is
>>> relatively easy/good case. If that happens repeatedly to certain
>>> players,
>>> they could do the following: Always when they play, open the log
>>> window -
>>> and e.g. move it toward the bottom border of screen. Or make it 
>>> very
>>> small
>>> (3 rows high or so).
>>>
>>> The problem is, the lines are logged there only when the window is
>>> open. So,
>>> opening it when it got stuck is too late.
>>>
>>> Have been thinking more than once, the client should log the lines
>>> even when
>>> window is closed (keep at least last 100 or 1000 or so), so when 
>>> one
>>> opens
>>> it later, there's something to fill in.
>>>
>>> That would in practice actually be not such a huge work.
>>>
>>>> A person is able to maintain the game progress by conceding the
>>>> battle.
>>> (the attacker? the one who gots stuck? Or is/can/must it be 
>>> conceded
>>> by the
>>> one who'se board DID come up?
>>>
>>> (How would the one who got stuck concede - if there's no battle
>>> board??
>>> Does the Masterboard concede help? Would be strange, since that one
>>> is meant
>>> to signal "I concede whole game". But it's fully possible that
>>> there's only
>>> one message called concede and server handled it differently
>>> depending on
>>> game state.  As we know, Colossus mostly works, not because it was
>>> so
>>> perfectly designed, but because not working things were eliminated
>>> one by
>>> one....)
>>>
>>> That's good. So the Client => server transport definitely works. 
>>> And
>>> probably also other way because game continues.
>>>
>>> So it might be something like client waiting for something from
>>> server (I
>>> remember there is/I added(?) something at one or two places...hm,
>>> hold a
>>> second. Yes, there was something related to engagements!
>>>
>>> What I added was related to the "when a player clicked to select 
>>> one
>>> engagement, it takes a while until server has processed it and 
>>> sends
>>> the
>>> according responses. In that time, player did not see "did it take
>>> it", so
>>> often clicked the legion again. Resulting in "illegal attempt to
>>> engage" or
>>> something on server side. To get rid of those, the client now is
>>> after
>>> clicking the legion in state "have sent engage request" and waits 
>>> to
>>> get the
>>> according response.
>>>
>>> (Something similar I also added not too long ago to the moving of
>>> legions.)
>>>
>>> So, if in that sequence of waiting for the ACK something else 
>>> comes,
>>> perhaps
>>> it gets not handled properly (discarded?). Or, like, there's
>>> (example) 4 different possible "responses" but I've programmed only
>>> 3
>>> of
>>> them to be recognized as valid replies to resolve from the "still
>>> waiting"
>>> state.
>>>
>>> So e.g. server has send something that should make client start
>>> handling of
>>> the battle, client does not react properly to it -- server waits
>>> that
>>> next
>>> thing comes from client ( like, response to the "flee"
>>> or "concede" or "negotiate" ?)  - In fact, attacker's possibility 
>>> to
>>> concede
>>> is usually the first, right?
>>>
>>> Conceding sends a specific message to server, and upon that server
>>> initiates
>>> a different processing.
>>>
>>>
>>> Above scenario would very well explain what happens, but only apply
>>> if
>>> it's always the active player who gets stuck.
>>>
>>> .... but of course it could be any number of other things as well
>>> :))
>>>
>>> Can you next times when you witness a getting stuck check out
>>> whether
>>> that is the case?
>>>
>>> Perhaps I find time to look into the code....
>>>
>>>
>>> Thx,
>>> Clemens
>>>
>>>
>>>
>>>
>>> On 2013-10-11 17:59, Jeff Matthews wrote:
>>>> RE: [Colossus-developers] Battle Hangs
>>>>
>>>> Clemens wrote:
>>>>
>>>> So, it's either client's EDT freezing (which the user would notice
>>>> very clearly ;-) , or the client for some reason not processing 
>>>> any
>>>> more data from server. (Which would manifest as one can use GUI 
>>>> and
>>>> all, menus, chat, right click a legion; but nothing that requires
>>>> server involvement, happens.
>>>>
>>>>>>>>> The highlighted is the situation. We go through all kinds of
>>>> menu options on both the masterboard and battleboard to try to
>>>> rehab
>>>> the situation. The menus are accessible and do work. Chat works,
>>>> too.
>>>> A person is able to maintain the game progress by conceding the
>>>> battle.
>>>>
>>>> This is really hard to troubleshoot without client side logs.
>>>>
>>>>>>>>> Yeah. I was going to try to modify the code to make some 
>>>>>>>>> logs,
>>>> but I soon learned I was too much of a novice.
>>>>
>>>> I can't say I understand the "stringify"/"de-stringify" process
>>>> very
>>>> well, except that it leads me to believe maybe it could be a bad
>>>> string or de-string is happening, which I'd find odd because I
>>>> can't
>>>> envision why it would work 85% of the time. I see nothing in the
>>>> process where the string conditions would vary, but then, again,
>>>> anything is possible.
>>>>
>>>> Jeff Matthews
>>>>
>>>> MATTHEWS | EASLEY | CHANEY
>>>>
>>>> 13430 Northwest Freeway, Suite 990
>>>>
>>>> Houston, Texas 77040
>>>>
>>>> Ph. (713) 223-4000
>>>>
>>>> Fax (281) 589-9000
>>>>
>>>> -----Original Message-----
>>>>  From: Clemens Katzer []
>>>>  Sent: Friday, October 11, 2013 5:55 AM
>>>>  To: col...@li...
>>>>  Subject: Re: [Colossus-developers] Battle Hangs
>>>>
>>>> No to both.
>>>>
>>>> 2)
>>>>
>>>> It's lowlevel stringify-sendviastream-unstringify, implemented 10+
>>>> years ago before all those fancy frameworks became trendy.
>>>>
>>>> I've once investigated how to replace that e.g. with simple RMI
>>>> (remote calls, which is rather old as well), but getting that then
>>>> stable that would probably take so long, that rewriting (for
>>>> example
>>>> in Python;-) all from scratch might be faster.
>>>>
>>>> 1)
>>>>
>>>> I don't think it's a communication ( = network ) problem in 
>>>> general
>>>> sense. The one luxury I've added in last year, is some kind of 
>>>> "are
>>>> you alive" polling. That is, because otherwise server can't
>>>> distinct
>>>> "line dead" from "client simply nothing sending because user has
>>>> not
>>>> clicked anything".
>>>>
>>>> If for such polls is no reply (30 secs? Not sure?) the other users
>>>> would see those "client not responding" messages in their
>>>> connection
>>>> log (which pops up if such messages come).
>>>>
>>>> So, it's either client's EDT freezing (which the user would notice
>>>> very clearly ;-) , or the client for some reason not processing 
>>>> any
>>>> more data from server. (Which would manifest as one can use GUI 
>>>> and
>>>> all, menus, chat, right click a legion; but nothing that requires
>>>> server involvement, happens.
>>>>
>>>> E.g. if the loop that handles messages coming from server bailed
>>>> out
>>>> due to a very severe exception. I think it catches almost all
>>>> throwable things so that should at least not remain unnoticed by
>>>> user.
>>>>
>>>>
>>>> One thing I changed not too long ago was decoupling the receive on
>>>> socket from processing it: now the socket thread is able to 
>>>> quickly
>>>> receive and store it ( that buffer is virtually unlimited, in
>>>> contrast
>>>> to lowlevel TCP/IP buffers); and the actual client processes them
>>>> in
>>>> it's now time. The socket thread also handles the alive polls.
>>>>
>>>> So, here could be a "client thread get's a hiccup with something
>>>> from
>>>> the buffer".
>>>>
>>>> The strange thing then would be here, that (as far as I was told 
>>>> so
>>>> far), the problem mostly manifests to users using old clients when
>>>> some other user uses newest client. I was hoping that when all
>>>> switch
>>>> to newest, it would go away :)
>>>>
>>>> This is really hard to troubleshoot without client side logs.
>>>>
>>>> BR;
>>>>
>>>> Clemens
>>>>
>>>> On 2013-10-11 07:12, Jeff Matthews wrote:
>>>>
>>>>> Battle Hangs
>>>>
>>>>>
>>>>
>>>>> The old problem of having the battleboard hang and disallow a
>>>>> player
>>>>
>>>>
>>>>> to make his initial set-up remains prevalent. I was just 
>>>>> wondering
>>>> if
>>>>
>>>>> this is a data communication issue to/from the server? If so, I
>>>>> was
>>>>
>>>>> also wondering if there is only a single method whereby Java
>>>>> allows
>>>>
>>>>> data communication to/from a server, or if there are other
>>>> compatible
>>>>
>>>>> modules which could be plugged-in and tried?
>>>>
>>>>>
>>>>
>>>>> Jeff Matthews
>>>>
>>>>>
>>>>
>>>>> MATTHEWS | EASLEY | CHANEY
>>>>
>>>>>
>>>>
>>>>> 13430 Northwest Freeway, Suite 990
>>>>
>>>>>
>>>>
>>>>> Houston, Texas 77040
>>>>
>>>>>
>>>>
>>>>> Ph. (713) 223-4000
>>>>
>>>>>
>>>>
>>>>> Fax (281) 589-9000
>>>>
>>>>
>>>>
>>>
>>>
>>> 
>>> ----------------------------------------------------------------------------
>>> --
>>>>
>>>>
>>>> October Webinars: Code for Performance
>>>>
>>>> Free Intel webinars can help you accelerate application
>>>> performance.
>>>>
>>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get 
>>>> the
>>>> most from the latest Intel processors and coprocessors. See
>>>> abstracts
>>>> and register >
>>>>
>>>> _______________________________________________
>>>>
>>>> Colossus-developers mailing list
>>>
>>>
>>>
>>>
>>> 
>>> ----------------------------------------------------------------------------
>>> --
>>> October Webinars: Code for Performance
>>> Free Intel webinars can help you accelerate application 
>>> performance.
>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>>> most
>>> from
>>> the latest Intel processors and coprocessors. See abstracts and
>>> register >
>>>
>>>
>>> 
>>> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Colossus-developers mailing list
>>> Col...@li...
>>> https://lists.sourceforge.net/lists/listinfo/colossus-developers
>>
>>
>>
>>
>> 
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>> most from
>> the latest Intel processors and coprocessors. See abstracts and
>> register >
>>
>> 
>> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Colossus-developers mailing list
>> Col...@li...
>> https://lists.sourceforge.net/lists/listinfo/colossus-developers
>
>
> 
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> most from
> the latest Intel processors and coprocessors. See abstracts and 
> register >
> 
> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
> _______________________________________________
> Colossus-developers mailing list
> Col...@li...
> https://lists.sourceforge.net/lists/listinfo/colossus-developers

> It was originally written using RMI.  (See commits starting at 
> r1611.)

Ah. Now I remember that we had the very same info exchange a while ago.
Like, in my previous life :)


> Slugathon actually works pretty well.

yeah. That reference to Python was non accidental...


> But I don't have time to write one right now.

As we all :)


> Why not just force all clients to use the same version as the server?

yes. Have been considering that already, too.In fact the code for it 
("integered" versions on client + server; at the moment the change would 
be from 4 to 5) exists, and indeed I did this enforcing to use the new 
version once before. It's merely a if clause on server side and 
responding accordingly. Both inform to "please update soon" and
informatively reject the login is possible.


>> But I don't have time to write one right now.

>As we all :)

I'll try to look into it.


All the best,
Clemens



On 2013-10-11 17:18, David Ripton wrote:
> On 10/11/2013 06:54 AM, Clemens Katzer wrote:
>
>> It's lowlevel stringify-sendviastream-unstringify, implemented 10+
>> years ago before all those fancy frameworks became trendy.
>> I've once investigated how to replace that e.g. with simple RMI 
>> (remote
>> calls, which is rather old as well),
>
> It was originally written using RMI.  (See commits starting at 
> r1611.)
> The problem is that RMI isn't firewall-friendly.  It uses two sockets
> instead of one, and opening the server -> client socket is 
> problematic
> if the client doesn't have a non-firewalled public IP address.
>
> At the time (2002), I couldn't find a decent Java networking library
> that did bidirectional communication, with either end initiating
> requests at any time, over a single socket, so I ended up writing my 
> own
> simple strings-over-socket protocol.  There are probably better 
> options
> today, but the protocol is already written and (mostly) debugged...
>
>> but getting that then stable that
>> would probably take so long, that rewriting (for example in 
>> Python;-)
>> all from scratch might be faster.
>
> https://github.com/dripton/Slugathon actually works pretty well.
>
> The problem is getting the client code onto less technical users'
> computers.  Python doesn't have an equivalent to Java Web Start, so
> users have to actually install software, which is too hard for some 
> of
> them.  Also, installing PyGTK onto a Mac is a pain.
>
> The ultimate solution is a JavaScript client that runs in the 
> browser,
> so users don't have to install anything.  But I don't have time to 
> write
> one right now.
>
>> The strange thing then would be here, that (as far as I was told so
>> far), the problem mostly manifests to users using old clients when 
>> some
>> other user uses newest client. I was hoping that when all switch to
>> newest, it would go away :)
>
> Why not just force all clients to use the same version as the server?
>
>> This is really hard to troubleshoot without client side logs.

On 10/11/2013 06:54 AM, Clemens Katzer wrote:

> It's lowlevel stringify-sendviastream-unstringify, implemented 10+
> years ago before all those fancy frameworks became trendy.
> I've once investigated how to replace that e.g. with simple RMI (remote
> calls, which is rather old as well),

It was originally written using RMI.  (See commits starting at r1611.) 
The problem is that RMI isn't firewall-friendly.  It uses two sockets 
instead of one, and opening the server -> client socket is problematic 
if the client doesn't have a non-firewalled public IP address.

At the time (2002), I couldn't find a decent Java networking library 
that did bidirectional communication, with either end initiating 
requests at any time, over a single socket, so I ended up writing my own 
simple strings-over-socket protocol.  There are probably better options 
today, but the protocol is already written and (mostly) debugged...

> but getting that then stable that
> would probably take so long, that rewriting (for example in Python;-)
> all from scratch might be faster.

https://github.com/dripton/Slugathon actually works pretty well.

The problem is getting the client code onto less technical users' 
computers.  Python doesn't have an equivalent to Java Web Start, so 
users have to actually install software, which is too hard for some of 
them.  Also, installing PyGTK onto a Mac is a pain.

The ultimate solution is a JavaScript client that runs in the browser, 
so users don't have to install anything.  But I don't have time to write 
one right now.

> The strange thing then would be here, that (as far as I was told so
> far), the problem mostly manifests to users using old clients when some
> other user uses newest client. I was hoping that when all switch to
> newest, it would go away :)

Why not just force all clients to use the same version as the server?

> This is really hard to troubleshoot without client side logs.

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

The old problem of having the battleboard hang and disallow a player to make
his initial set-up remains prevalent.  I was just wondering if this is a
data communication issue to/from the server?  If so, I was also wondering if
there is only a single method whereby Java allows data communication to/from
a server, or if there are other compatible modules which could be plugged-in
and tried?

Jeff Matthews
MATTHEWS | EASLEY | CHANEY
13430 Northwest Freeway, Suite 990
Houston, Texas 77040
Ph. (713) 223-4000
Fax (281) 589-9000

All right.

-Cle.


On 2013-10-01 16:53, Bruno Wolff III wrote:
> On Tue, Oct 01, 2013 at 12:51:22 +0300,
>   Clemens Katzer <cle...@cl...> wrote:
>>
>>>Since the changes seemed pretty minor I am going to do the upgrade 
>>> in
>>>all of the active Fedora releases.
>>
>>New 0.14.0 is a very minor (even trivial) change compared to 
>> "original" 0.14.0 but there's lot of changes compared to previous 
>> official releases 0.13.x. Hence the change to 0.14.x.
>>
>>http://colossus.sourceforge.net/docs/RecentChangesDetails.html
>
> Yeah, I read that. But they aren't the kind of changes that will be
> disruptive to people who have been playing 0.13.2. They are minor in
> that sense.

On Tue, Oct 01, 2013 at 12:51:22 +0300,
   Clemens Katzer <cle...@cl...> wrote:
>
>>Since the changes seemed pretty minor I am going to do the upgrade in
>>all of the active Fedora releases.
>
>New 0.14.0 is a very minor (even trivial) change compared to 
>"original" 0.14.0 but there's lot of changes compared to previous 
>official releases 0.13.x. Hence the change to 0.14.x.
>
>http://colossus.sourceforge.net/docs/RecentChangesDetails.html

Yeah, I read that. But they aren't the kind of changes that will be 
disruptive to people who have been playing 0.13.2. They are minor in 
that sense.

> Since the changes seemed pretty minor I am going to do the upgrade in
> all of the active Fedora releases.

New 0.14.0 is a very minor (even trivial) change compared to "original" 
0.14.0 but there's lot of changes compared to previous official releases 
0.13.x. Hence the change to 0.14.x.

http://colossus.sourceforge.net/docs/RecentChangesDetails.html

In particular, the new release has some bug (at least that one) that 
starting a battle might hang the game (although it seems related to if 
someone uses the newer version it crashes for a player using the 
previous one).

I made the 0.14.x in the hope when getting it into much wider use to be 
able to improve chances to reproduce/fix the issues. Thus waiting for a 
next minor bugfix release might be good idea. But then, I have no idea 
whether or when that will happen.

-Clemens



On 2013-09-30 06:19, Bruno Wolff III wrote:
> On Tue, Sep 24, 2013 at 19:21:51 +0300,
>   Clemens Katzer <cle...@cl...> wrote:
>>
>>> If so, what's the rev number that should be used?
>>
>>
>>trunk:5331. First try was 5328. Tag might still me only from 5328.
>
> 0.14.0 is in Rawhide and Fedora 18, 19 and 20 testing.
>
> Since the changes seemed pretty minor I am going to do the upgrade in
> all of the active Fedora releases.