Re: [Freecol-developers] FreeCol 1.0.0 Released

[Michael T. Pope]

On Mon, 2 Jan 2023 23:32:44 +
Stian Grenborgen  wrote:
> FreeCol 1.0.0 has now been released.

Congratulations and thanks to all involved.

(Hope to be back to the bug list soon:-)

Cheers,
Mike Pope


pgpD6cOiKeaLk.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Simple mods as options

[Michael T. Pope]

On Sun, 25 Sep 2022 17:46:42 +
Stian Grenborgen  wrote:
> I have noticed that some of the game/client options could have been 
> implemented using a mod ... and some of the mods (like convertUpgrade) seem 
> more suitable for an option.
> 
> Perhaps we should make a SpecificationChangeOption with a specification as a 
> child element? The option could be displayed as a checkbox for enabling the 
> change.
> 
> Another possible solution would be having an option called 
> AlternativeModOption where the player could choose from a dropdown list of 
> mods. Mods like this would be hidden from the normal mod list. This could be 
> used for functionality like choosing between "Default map controls", "Small 
> Map Controls" and "Compact Map Controls".
> 
> Would a change like this make stuff easier to find/understand ... or do you 
> think it might make it unnecessarily complex?

I am not seeing a big win here, other than (apparently) we have useful
mods[1] that could have better visibility.  There have been a few whinges
that we have too many options so I am hesitant to endorse opening up
a whole new category:-).

Cheers,
Mike Pope

[1] IIRC the Casas mod was a mod because:
- someone wanted to play a "classic Col1 but with obvious bugs like Casas
  fixed" game, but did not want all the extras in the freecol-ruleset
- the unit type change code was pretty new/volatile at the time so it was
  less likely to cause general bugs if it started as a mod
...so notwithstanding my above reservations, by now it is probably a good
candidate to graduate to an option.


pgpSeogVLbmSk.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Bartolome De las Casas Bonus isn't persistent

[Michael T. Pope]

On Sat, 24 Sep 2022 13:10:58 -0700
David Lewis  wrote:
>[Casas]

We discussed Casas years ago, and agreed the Col1 behaviour was broken.
You might want to look at the convertUpgrade mod which emerged from that
discussion.

Cheers,
Mike Pope


pgpw4yywNM421.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] New AI Colony Management

[Michael T. Pope]

On Sat, 3 Sep 2022 08:37:48 +
Stian Grenborgen  wrote:
> I'm currently working on a new AI system for managing the colonies.

Its indeed time someone had another crack at colony management.  All I can
say in defence of its current state is that every rewrite so far has been
an improvement:-).

Cheers,
Mike Pope
 


pgpLbPCAkbZ1M.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Fixing issues with production on tiles

[Michael T. Pope]

On Sat, 3 Sep 2022 08:51:07 +
Stian Grenborgen  wrote:
> The main problem with the rewrite is lack of tests for the correct tile 
> production values ...

I thought we had *some* tests... TileTest exists.

Cheers,
Mike Pope


pgpO1uAYBsNlm.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Fixing issues with production on tiles

[Michael T. Pope]

On Sat, 3 Sep 2022 08:51:07 +
Stian Grenborgen  wrote:
> The main problem with the rewrite is lack of tests for the correct tile 
> production values ... 

There is/was effort to determine the Col1 values, but as you note, it is a
lot of work.  See:
https://sourceforge.net/p/freecol/wiki/WWC1D%20-%20resource%20output%20v2/
and all the pages with a "WWC1D - resource" prefix visible at:
https://sourceforge.net/p/freecol/wiki/browse_pages/

Not knowing what is right has rather dampened enthusiasm for work in this
area.

Cheers,
Mike Pope


pgpsJBNN3piTH.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] FreeCol 0.13.0

[Michael T. Pope]

On Sun, 19 Jun 2022 07:33:32 +
Stian Grenborgen  wrote:
> I think we should release 0.13.0 rather soon. Are there any release blockers 
> left?

Go for it.  Enough bugs have been fixed.  I have some more fixes underway
starting with the older stuff, but available time is unpredictable.
 
> BTW, I will probably be removing some/all of the skulls from the new 
> InfoPanel skin before the release -- since it made some of our players 
> uncomfortable. In addition, some users seem to be associating the skulls with 
> pirates rather than baroque or Vanitas [1]. It's a bit sad since I really 
> like the new panels as they are.

Agreed, and it is not as if we lack pirates.  However as always, do not
trust me on presentation issues.

Cheers,
MTP



pgpsVnHSda0uA.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] FreeCol with Java

[Michael T. Pope]

On Thu, 5 May 2022 17:45:19 +
Stian Grenborgen  wrote:
> I have just added a new Windows installer for 0.12.0 that includes a JVM:
> https://sourceforge.net/projects/freecol/files/freecol/freecol-0.12.0/
> 
> If this works properly, I can look into building a new release package for 
> macOs that includes a JVM as well -- and make automated build jobs on Github.
> (unfortunately the packages needs to be built on the target system)

Looks like you just elected yourself release manager:-).

Speaking of which, Caleb makes a fair point that BR#3248 (fixed) is really
annoying and merits a release bump.  It would be nice to fix the colopedia
fail (BR#3250) first though, and I have not even had a chance to look at
BR#3253 which sounds bad.

Cheers,
Mike Pope


pgpNgilGXifeh.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Connection.request/askMessage

[Michael T. Pope]

On Sun, 1 May 2022 09:33:19 +
Stian Grenborgen  wrote:
> I'm wondering why we are using Connection.request instead of just 
> Connection.sendMessage.

Almost certainly its historic.  When the DOM-removal was happening we went
to really conservative messaging (e.g. overuse of askMessage), which slowed
the game down but made it nearly synchronous and deterministic, and thus
easy to debug. When that work was complete things were loosened up a bit
(e.g. calling handlers in their own thread).  I doubt we were coherent or
consistent about this, but it did get to the point that the message
handling was both working faster and easy to debug now that it was logged
if required. At that point, profiling showed all the lag was in the GUI,
and I was buried by non-FreeCol work, so messaging was ignored.
 
> The point of having Connection.askMessage is connecting the reply to the 
> answer ... so that the calling thread can be blocked until the answer has 
> been received. It's for making an asynchronous process synchronous.  
> 
> Yet the process is made asynchronous again by calling the handler in 
> Connection.request.
> 
> The main difference between Connection.request and Connection.sendMessage is 
> that the caller to the former gets blocked until the reply has arrived, while 
> for the latter it does not. Please note that this only happens for the 
> calling thread ... there's nothing preventing another thread from making 
> another request at the same time. The reply we are waiting for can already 
> have been invalidated. The value of this type of locking is dubious.

This was again probably just over-caution.  No one was in a rush to deal
with a bunch of race conditions, like happened the time I tried making
moveMessage not have to wait:-).  That said, there is a lot of code in the
client InGameController which reads:

  if (askServerToDoSomething(...)) {
if (looksLikeTheServerDidIt(...)) {
  doStuffThatDependsOnTheChange()

...where the first test sometimes just succeeds if the client
sent the message (ServerAPI.send), but often waits for a server
response usually containing an UpdateMessage that provides the requested
change (ServerAPI.ask).  So, point taken about the dubious locking, but
the client code tends to explicitly enforce the required sequential
behaviour.

Now, I expect there are individual cases where asks can be sends, but we
would have to look hard at each case.  Notably, as you say, the most common
action (move) is probably a bad candidate.

> In addition, any time it is used we need to consider when to abort the 
> execution and if a timeout should be added to the call.

There are certainly timeout cases already, needed to avoid indefinite
stalls in multiplayer.  See the various uses of TimedSession.  There are
probably more cases on the server side where a more asychronous style
would work.

> There are two approaches we can use instead of the current solution:
> 
> 1. Have a completely asynchronous process when sending messages.
> 2. Execute Connection.request/askMessage on separate threads (either 
> popup-threads or have a thread poll/ExecutorService).

Whatever is easier to maintain:-).  My main concern is that we have cases
that *must* block, so a synchronous layer will be needed on top.

> I am also noticing that we are calling Connection.request from the Event 
> Dispatching Thread. This makes the user interface block until the answer has 
> been received. The Connection.askMessage, and by extension 
> Connection.request, should only be called from worker threads.

Yep, I have historically been pretty casual whether we are in the event
thread or not.  Not good practice I know.  Where are you seeing this?
I just looked at what I thought would be a likely case, but the emigration
handling looks good as the server messaging happens in its own thread
inside DialogCallback.

Cheers,
Mike Pope


pgp4cuqUp0uuu.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

[Freecol-developers] FreeCol 0.12.0

[Michael T. Pope]

FreeCol 0.12.0 has been released.  The release notes are at:
https://sourceforge.net/p/freecol/wiki/0.12.0%20Release%20Notes/

Yeah, it took a while.

Cheers,
Mike Pope


pgpVsrU2s9jPk.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Updates/questions on infrastructure

[Michael T. Pope]

On Wed, 27 Apr 2022 21:11:20 +
Stian Grenborgen  wrote:
> * We are now using https for freecol.org
> * The master branch on SF.net is automatically mirrored to GitHub on every 
> push (using a server hook).
> * GitHub Actions is used for building on every push, and making the packages 
> available on the workflow in a single ZIP file (see [1]).

This is very nice.

> I can automate the release, but there would be a lot of releases if we do it 
> automatically for every push. Some suggestions:
> 
> 1. We can have the files (separately) available on the workflow. The testers 
> would then always get the latest build. The drawback being all files are 
> wrapped in a zip-file anyway -- so, for example, the jar file would be inside 
> a zip file.
> 
> 2. We can trigger the release process manually
>   a. ...by making changes to a file (like "CHANGELOG.md" or 
> "TESTRELEASE.md"). The entire text in that file can be used as release notes.
>   b. ...by publishing a release from GitHub.com (the files would be 
> automatically included).
>   c. ...by manually starting the workflow from GitHub.com.
> 
> What would you like as a solution? ...or should I just pick the easiest one 
> (no. 1)?

Easy, and it might as well be CHANGELOG.md as it already exists.  Please
add a mention of what you decide on to the developer doco, I keep
forgetting what the github is doing.

BTW, had an hour or so free this morning, so I did something really odd...
I played freecol:-).  Did not crash it and it was snappy.  We are looking
good for an official release.

Cheers,
Mike Pope


pgpaN4pmqvr_9.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] [freecol:bugs] Re: #3247 Strange queue of AI ships to Indians settlements

[Michael T. Pope]

On Sun, 24 Apr 2022 09:52:03 +
Stian Grenborgen  wrote:
> We equip non-scouting specialists with horses, muskets and tools to better 
> utilize the capacity of the ship. These units should never be sent on a 
> ScoutingMission (likewise for soldiers and pioneers).

This "should not happen":-), as the specialists should have been given a
WishRealizationMission to go to the colony that needs them.  However I can
believe that the mission allocation is borked.  I will look at it.

> It's easy enough checking for this in the mission, but perhaps a better 
> solution would be having the goods transported separately? This would make it 
> more fun for human players utilizing privateers (making the ship easier and 
> more fun to sink). The AI gets extra ships (by cheating) so the difficulty 
> should not be a problem.

Point taken on the privateers, but I think the AI should be allowed to
transport things efficiently if it can.  I really do not like using the AI
cheats as a justification for anything (ideally we should be working on
cheating less).  Lets see if I can fix the current failure.

Cheers,
Mike Pope


pgpL8P1M3aLD3.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] [freecol:wiki] mpope modified page 0.12.0 Release Notes

[Michael T. Pope]

On Sun, 24 Apr 2022 10:46:23 +
Stian Grenborgen  wrote:
> > [ https://sourceforge.net/p/freecol/wiki/0.12.0%20Release%20Notes/ ]
> > In game music from Alexander Zhelanov
> 
> I think we should postpone adding the music until FreeCol 0.13.0, and make 
> that release one/two month(s) from now. That way, we have more tracks 
> available -- avoiding making the players tired of hearing the same few tracks 
> being played over-and-over.
> In addition, there are several changes requiring new translation strings that 
> I have postponed since we are close to a release. It would be nice having 
> another release rather soon.

No worries, I have not had a chance to look at the music at all, so your
call.

> So, my suggestion is:
> 
> 1. Make a new nightly build since there are multiple important fixes that 
> have been added lately.
> 2. Make an announcement on the forum and Discord channel that we will be 
> releasing 0.12.0 in a few days -- and that testing and bug reports (or even 
> reports that everything works fine on a specific operating system) is 
> especially appreciated.
> 3. Publish our plan for a 0.13.0 release on the forum so that 
> Alexander/Misiulo know the deadline if they want something included.
> 4. Publish our plan for a 1.0.0 release on January 2nd, 2023.

No problems with that, and I definitely can see the point with #2, given
that I am still finding event-dispatch-thread related crashes.  What would
be really good is an intense burst of testing.  Where is our publicity
manager--- you there Blake?

Cheers,
Mike Pope



pgpgmH0tltFiq.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Cortado Bug

[Michael T. Pope]

On Sun, 24 Apr 2022 08:00:12 +
Stian Grenborgen  wrote:
> There is a bug in Cortado that prevents playing the intro movie on systems 
> where "java.vendor" does not contain a space:
> https://gitlab.xiph.org/xiph/cortado/-/blob/master/src/com/fluendo/player/CortadoPipeline.java#L601
> 
> I have committed a workaround:
> https://sourceforge.net/p/freecol/git/ci/b7872e6b5f2920a844b45fc8fdccc35e8c799a41/
> 
> ...although I would suggest we resurrect our own fork of Cortado as the 
> Cortado project seems to be dead.

Ugh, this has been a frequently broken area for some time.  Is there a
official-Java media framework these days?

Cheers,
Mike Pope


pgpItScOJ4x7c.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] FreeCol 1.0

[Michael T. Pope]

On Fri, 22 Apr 2022 20:29:39 +0930
"Michael T. Pope"  wrote:
> .. only one that I consider release blocking,
> which is Marcin's REF immediate surrender problem in #3246.  So that is
> now my high priority weekend job.

I think we are good for release following git.c9eedcf.  The REF is now
more stubborn, and when it does surrender the log will say why. 

> The AI ship fail (3247 == 3228) is "would be nice".  Perhaps I am too used
> to the AI failing.  Next on the list.

Will look at this soon.  But first, the release notes could do with some
updates, and I have scrounged up an old mac laptop so I can test the mac
build.

Who wants to actually do the release?:-)  The "current" procedure is
actually documented.

Cheers,
Mike Pope



pgpgv6Mq_PKqn.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] FreeCol Website

[Michael T. Pope]

On Sat, 23 Apr 2022 18:54:47 +
Stian Grenborgen  wrote:
> We are still running our website www.freecol.org using http. It's possible 
> switching over to https, while keeping our own domain name, by requesting it 
> from SourceForge. They would need to manually add our domain to the list of 
> SubjectAlternativeName on their server certificate.
> 
> Should I request the change? ...and migrate our website over to 
> vhost2.sourceforge.net?

I am in favour of being on https.

> Asking since there have been some suggestions about moving the website to 
> Github Pages, which also supports https with our domain name, and I don't 
> want to ask SourceForge unless we plan on keeping our website there.

I am still not in favour of moving fully to github.  The sticking point for
me has always been that github has nothing comparable to the SF forums,
which I believe are valuable.  That said, the website is a separable part
of the overall FreeCol project, it can live where the people who want to
work on it find the most convenient.

Cheers,
Mike Pope


pgpibXa4pc7Ap.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] GitHub Mirror and "Nightly" releases

[Michael T. Pope]

On Sat, 23 Apr 2022 17:06:49 +
Stian Grenborgen  wrote:
> > One issue with the process is it isn't consistently timed as I have to 
> > physically perform each part
> > of the process. I also cannot generate the MacOS installer.
> 
> The Mac bundle can be created using GitHub Actions. We can also automatically 
> both build and publish nightly builds. Release notes can be automatically 
> generated using commit messages (although such a commit log might not be user 
> friendly). It's apparently even possible to automatically post messages to 
> Discord and Facebook -- although I have not tried that before.

We need to test the mac builds, there are reports of it being broken.

WRT to release notes, there is an early draft underway (
https://sourceforge.net/p/freecol/wiki/0.12.0%20Release%20Notes/
) , albeit it is way out of date and now wrong in places.  Notably we need
to settle the minimum Java version.  In the absence of violent opposition
I will commit the well tested patch I have that takes it from 8 to 11.

Cheers,
Mike Pope



pgp5GJAPTYPHC.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] FreeCol 1.0

[Michael T. Pope]

On Fri, 22 Apr 2022 13:54:05 +0930
"Michael T. Pope"  wrote:
> I will try to do the review this evening.

How about that, we are in pretty good shape.  I have looked through the
bugs back to 0.11.6, and found only one that I consider release blocking,
which is Marcin's REF immediate surrender problem in #3246.  So that is
now my high priority weekend job.

The AI ship fail (3247 == 3228) is "would be nice".  Perhaps I am too used
to the AI failing.  Next on the list.

There are quite a few bugs stuck in a needinfo state, if anyone wants to
take a shot at improving the release quality:

3243: Gameplay bugs
3229: modifications reset after save
3225: too much lumber
3222: Colony population displayed incorrectly when spying
3217: Colony gains production bonus incorrectly
3188: Cannot establish mission w/ captured missionary?
3183: Labor Advisor window got a glitch. (freecol-nightly-2020-02-27)
3167: Ship cannot return from Europe
3162: Error "The server can not do that." when trying to haggle
3155: Wrong Starting Units
3151: Royal expeditionary land forces not increasing
3149: H - go to city command failure
3146: Suffered a big savegame corruption error
3134: User Interface Issues
3081: Master Gunsmith Doesnt have connections
3062: Map Explored Regions Error
3035: Broken key mapping for closing panels
3025: Incorrect saves (map editor)
3012: Turn report exclusions not working

I suspect several of these are actually fixed, or moot, or both.

Finally I have some graphics BRs for Stian:-).  Are #3216 and #3209 fixed?
And did your recent work include fixing the river selection panel #2926?

Cheers,
Mike Pope


pgpSTgKIi0edr.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] FreeCol 1.0

[Michael T. Pope]

On Thu, 21 Apr 2022 18:09:51 +
Stian Grenborgen  wrote:
> We have made great progress on FreeCol since our last release, and should 
> make an official release rather soon.
> 
> I think releasing the game as 1.0 will show the level of maturity our game 
> has reached ... and also signify the awesome new additions to the game:

All this is true and great progress, but we have always said 1.0 will be
fully Col1 compatible (at least in classic mode).  I do not think we are
there yet.  A look at the WWC1D? wiki page will show that we do not even
know how compatible we are:-).

We *should* indeed do a release though, whatever the number it gets.  It
is overdue.  I was not pushing hard there lately as (apart from the usual
time crunches) the worst blocker bug was the total breakage (some
self-inflicted:-P) of the TradeRouteInputPanel.  Which just got fixed this
week, bravo Stian. The next worst one I know is the queue of AI ships
(BR#3228) which I hope to look at one the weekend (long weekend in .au,
hooray), but letting AI fail block release is a bad idea.

However I probably should do a quick review of the state of the bug list
to see if we have other bad enough bugs to be considered release blockers.
I will try to do the review this evening.

Cheers,
Mike Pope


pgpdOvjGTqSgf.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Units in Fog of War

[Michael T. Pope]

On Sun, 3 Apr 2022 11:22:41 +
Stian Grenborgen  wrote:
> I just noticed that units are removed immediately from display when no longer 
> within canSeeTiles. In the 0.10 releases they were removed at the end of turn 
> which I think makes more sense.
> 
> Anyone who can remember if this was intentionally altered or not?

I do not remember any discussion in that area.  It probably happened
in one of the MapViewer rewrites, of which there were at least two since
0.10 but I was not involved in either.  It might also be a consequence of
the work to give per player views of unseen tiles, which was me, and if so
it was not intentional.

Cheers,
Mike Pope



pgpwwfLuc3I0Z.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

[Freecol-developers] Fw: FreeCol Wins an Award from SourceForge

[Michael T. Pope]

Apparently FreeCol has qualified for some sourceforge awards.  Here is the
text of the message I received.  Odd that there is a duplicate... 

Cheers,
Mike Pope

Begin forwarded message:
*
FreeCol Wins an Award from SourceForge
*


Hi Mike Pope,

Congratulations! FreeCol has just been recognized with the following
awards by SourceForge:


Community Leader

Community Choice

Open Source Excellence

Open Source Excellence

SourceForge Favorite


These honors are awarded only to select projects that have reached
significant milestones in terms of downloads and user engagement from the
SourceForge community.

This is a big achievement, as your project has qualified for these awards
out of over 500,000 open source projects on SourceForge.

SourceForge sees nearly 30 million users per month looking for, and
developing, open source software.

These award badges will now appear on your project page, and the award
assets can be found in your project admin section.

To recognize FreeCol’s achievement, we’ve awarded you with the
aforementioned awards, which you can see at
https://sourceforge.net/p/freecol/admin/files/badges/.

Now that FreeCol is an official winner of the these awards, you have
express permission to use the award badges wherever you’d like.

Feel free to proudly display the awards on your personal or organizational
website, social media, or anywhere else you’d like.

You can get the award badge assets here:
https://sourceforge.net/p/freecol/admin/files/badges/

Congrats again on winning and keep doing amazing work because SourceForge
and our users appreciate it!

Thanks,

The SourceForge Team







‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 












Find, Create, & Publish Open Source Software for free.







Hi Mike Pope,



Congratulations! FreeCol has just been recognized with


the following awards by SourceForge:



Community Leader 

Community Choice 

Open Source Excellence 

Open Source Excellence 

SourceForge Favorite 

These honors are


awarded only to select projects that have reached significant milestones in terms of downloads and user engagement from the SourceForge community.


This is a big achievement, as your project has qualified for

these awards

out of over 500,000 open source projects on SourceForge.

SourceForge sees nearly 30 million users per month looking for, and developing, open source software.

These award badges

will now appear on your project page, and the award assets can be found in your project admin section.



To recognize FreeCol’s achievement, we’ve awarded you with the

aforementioned awards, which you can see below:










Now that FreeCol is an official winner of the these awards, you have express permission to use the award badges wherever you’d like.



Feel free to proudly display the awards on your personal or organizational website, social media, or anywhere else you’d like.


You can get the award badge assets here.

Congrats again on winning and keep doing amazing work because SourceForge and our users appreciate it!

Thanks,

The SourceForge Team









This e-mail was intended for: mp...@computer.org

Unsubscribe from these notifications
Privacy policy

PO BOX 2452, La Jolla, CA 92038
















pgpUaOKEzfR0m.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] New groups for Client Options

[Michael T. Pope]

On Thu, 27 Jan 2022 18:16:03 +
Stian Grenborgen  wrote:
> One thing I find strange, however, is why the client options are stored with 
> the save game. The separation between game options and client options was 
> originally in order to separate global options from those that should 
> influence a single game.

Now that you mention it I have no idea... looks like we had a feature
request:

  commit b835c8e15b974a6c40ef54c904370a7843677623
  Author: Michael Vehrs 
  Date:   Sun Apr 24 14:58:19 2011 +

  Read client options if present in savegame file. Partially implements 
FR#3008377.

Rather old history now, using the previous SF request numbers, but it looks like
[IR#99](https://sourceforge.net/p/freecol/improvement-requests/99/) in the new 
format.
However, I do not understand why the involving the savegame was necessary.
Perhaps reading the client options were borken at the time.

I like the principle of game options containing game specific matter and
client options being global.  I can not think of any cases where it would
make sense to have different client options in different games...

> Originally, the mod list in client options should only be applied for new 
> games -- with the exception of mods that contain no game altering behavior 
> (like graphics mods). The mod list for a specific game should be stored with 
> the savegame ... but no other client option should (in my opinion).

...except for the mods, and perhaps the language option (which is already
special).  IIRC the saved game effectively contains the game-altering mods
as they change the spec and the spec is saved.  However the code seems to
be reloading the active mods when it loads a saved game, which is probably
needed to get the Resources right but should not be needed for the spec.  I
should look into this.

If the client options mod list is only applicable to new games we should
improve the documentation and comments to make that clearer.

> I find it annoying when my preferences are changed when loading a savegame 
> ... forcing me to make the same client option change for multiple games. Do 
> we really want that behaviour ... or can we change it?

We certainly can.  However I am puzzled about what is going on ATM.
loadClientOptions is pretty clear that it loads (in order):
1. The base installed client-options.xml
2. The client-options.xml from an optionally supplied saved game
3. The user client-options.xml.
with the expectation that later loads override previous loads.  Is this
not happening for you?  If so we have a bug.

> > However, point of clarification, client-options.xml has the warehouse,
> > messages and other options inside the interface group--- was that
> > intended?  They were previously direct children of the clientOptions group.
> 
> Yes, that was an intended change in order to have fewer options on the top 
> level. Please do suggest other groups/layouts that might work better.

Please ignore any suggestions I make on presentation issues:-).  I will
finish the backward compatibility work soonish.

Cheers,
Mike Pope


pgphCrztevhFr.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] New groups for Client Options

[Michael T. Pope]

On Sun, 16 Jan 2022 17:50:24 +
Stian Grenborgen  wrote:
> I have introduced a few new option groups in order to better organize the 
> client options:

I have a patch to gracefully update old games to the new format.
However, point of clarification, client-options.xml has the warehouse,
messages and other options inside the interface group--- was that
intended?  They were previously direct children of the clientOptions group.

Cheers,
Mike Pope


pgpojIti0TN19.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] New groups for Client Options

[Michael T. Pope]

On Sun, 16 Jan 2022 17:50:24 +
Stian Grenborgen  wrote:
> I have introduced a few new option groups in order to better organize the 
> client options:

No issue with the reorganization.  However I suspect the backward
compatibility code needs some updates as a result.  I will be back to
coding for FreeCol by the last week of January at the latest, so I will
look after it.

Cheers,
Mike Pope


pgpRiSb4Fc0oJ.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] (no subject)

[Michael T. Pope]

On Wed, 22 Dec 2021 12:31:03 + (UTC)
D Blakeley  wrote:
> Hey guys,
> As some of you know I'm not programmer so anything I say about this should be 
> taken with a grain of salt lol. However today I noticed some panic in the fan 
> game community regarding fan games made with Java due to a 'Java Log4j 
> exploit'...

I probably should have spoken sooner, given I do Computer Security
professionally.  The log4j bug has been around for a bit, and you are right
to be concerned because it is extremely bad.  Rest assured that freecol is
log4j free, and if it had not been, I would have killed its use with fire
and pushed out an emergency release.

Cheers,
Mike Pope


pgpsTQXpqb_1p.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Coronado / PF83

[Michael T. Pope]

On Wed, 22 Dec 2021 17:53:59 +0100 (CET)
Stefan Fellner  wrote:
> > I think that might be overkill.  I might be misunderstanding here.  What
> > is currently wrong?
> >
> Col1 (v3) would grant you the 11x11 sight radius for all colonies, also newly 
> founded, also your own colonies. Also with the ability seeAllColonies this is 
> not what Coronado would grant you in freecol (at least not in my tests).

Did you test classic or freecol rules?  classic has a hack to reveal the
full 11x11, as required for Col1 compatibility. freecol-rules does
not.  I do not remember what I did at the time, but judging by
reaction on PF83 I probably decided it was excessive for freecol.  Is the
classic-rules hack not working?

FreeCol (the program, not the ruleset:-) (should) distinguish visibility
from exploration.  Exploration just reveals the terrain and improvements.
Visibility is exploration plus units.  Here is what I think we have ATM:

classic-rules:
- 11x11 exploration for all colonies when Coronado joins
- ongoing 5x5 visibility of your own colonies only

freecol-rules:
- 5x5 exploration for all colonies when Coronado joins
- ongoing 5x5 visibility of all colonies (provided by seeAllColonies)

So if I understand aright, the problem is that classic-rules should
also provide 11x11 exploration for new colonies?

If so, IMHO the best way to do this is in the update sent to
players from the build-colony code.

Cheers,
Mike Pope


pgpyvYJ8j_UDC.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Coronado / PF83

[Michael T. Pope]

On Tue, 21 Dec 2021 19:26:35 +0100 (CET)
Stefan Fellner  wrote:
> I added to your ServerPlayer#csEndTurn (you added for laSalle), also the 
> coronado-reveal territory call, for in col1 that also applies for all newly 
> founded colonies.

I think that might be overkill.  I might be misunderstanding here.  What
is currently wrong?  If it is that Col1-Coronado grants display of new
colonies, then AFAICT that is what we do in the freecol-ruleset, so the
easy way to fix that is just to add the:
   
  

from .../rules/freecol/specification.xml to
.../rules/classic/specification.xml.  See Player.getVisibleTileSet.  That

> -> created branch therefore, 
> 
> jazzrexl/add-coronado-seeallcolonies-end-of-turn

Nitpicks.
1. Please do not create new functions without javadoc.
2. cs*() routines have the convention that the ChangeSet argument is last.

Cheers,
Mike Pope


pgpUSIuSqOPTx.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] La Salle Bonus

[Michael T. Pope]

On Thu, 16 Dec 2021 20:36:38 +1030
"Michael T. Pope"  wrote:
> > On the place to put it, I think it's fine to do it at turn-end, if that's 
> > too much traffic.
> 
> Lets put it there for now and see how it behaves.  I think it makes the
> most sense with the destroyed building case above.

Trial implementation committed (git.9a8728f).

Cheers,
Mike Pope


pgpHE2swDBGkb.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Question: Building Colony / Claim Land

[Michael T. Pope]

On Thu, 16 Dec 2021 17:49:01 +0100 (CET)
Stefan Fellner  wrote:
>[Lots of testing]

Argh, that is indeed complex and weird.  I really do not like mere
exploration making implicit land claims.  If we implemented that directly
the native anger levels would go through the roof.

> Now what do we want to do for freecol / classic ruleset?
> -
> 
> I suggest the following, more clear way:
> Leave the handling as it is now, claim land only if:
> - Founding a colony
> - Improving a tile (pioneering)
> - Working a tile in the colony (potential payment / stealing of native owned 
> as it is)

Agreed.  Note also we have implemented land claims by wandering
natives, however there were complaints that they claimed too much land, so
native land claims occur with probability proportional to proximity to the
brave's home settlement, subject to a maximum.

> But, I would add the settlement ownership like I did in the patch, if a tile 
> get's claimed by an improvement action. Then you wouldn't loose potential 
> resources.

Done (git.96b1cb917e).  Tiles claimed by an improvement action are now
owned by a neighbouring colony owned by the same player.

> Maybe claim the land for settlements right away when founding the colony, but 
> only tiles unowned.

Done as foreshadowed, with the new "Claim all tiles" game option, enabled
in classic mode, disabled in freecol mode (git.1ce7690fa9).

Cheers,
Mike Pope



pgpQbo31Gxf62.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] La Salle Bonus

[Michael T. Pope]

On Thu, 16 Dec 2021 10:42:49 +0100 (CET)
Stefan Fellner  wrote:
> If you have more col1 questions / uncertainity - I am happy to share 
> screenshots, or try it on the spot.

There are a bunch of open questions on the wiki I mentioned earlier.  That
would be a great mission for you to take on: Kill the WWC1D Wiki (by
answering and fixing all the questions:-)

> Back to La Salle:
> The behaviour after capture could be discussed - I think that's only because 
> col1 would apply the bonus the moment you raise pop from 2 to 3, and the 
> moment La Salle joins congress.
> So if you capture the colony with pop >= 3, you won't get the stockade until 
> you add another pop when pop >= 3 (double checked in the game).
> So it's maybe a bit of an exploit by me, because i often like to just disband 
> foreign colonies,
> but it's also reasonable to be able to do it (scorched earth ;)).

Agreed.  No one likes the stockade restriction.  It is totally reasonable
to be able to abandon a colony.  I understand the gameplay restriction in
Col1, and we support it, but if the colonists decide to torch the stockade
and leave town who is stopping them?:-)

There is another interesting case.  We have experimental support for
natural disasters.  One of these is the destruction of a building.  I
think a native attack can do this too.  So... if they knock out the
stockade, does it get rebuilt instantly?  Or in classic rules, should a
player with an unwanted colony try to annoy the natives and leave it
undefended in the hope that they burn the stockade, allowing the colony to
be abandoned?

> That you get La Salle bonus for new colonies after La Salle joined, that's 
> IMHO an requirement, I would consider it a bug (as of your policy diffs to 
> col1 for classic ruleset -> bug).

Yep.  Screenshots are convincing.  Its a bug.

> On the place to put it, I think it's fine to do it at turn-end, if that's too 
> much traffic.

Lets put it there for now and see how it behaves.  I think it makes the
most sense with the destroyed building case above.

Cheers,
Mike Pope



pgpPSC2sRDnYa.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Question: Building Colony / Claim Land

[Michael T. Pope]

On Thu, 16 Dec 2021 10:14:36 +0100 (CET)
Stefan Fellner  wrote:
> here's the screenshots from col1 regarding claim land.
> -> before it's iroquois land, already after I moved the pioneer to the tile, 
> the land got claimed (even before i started to improve the tile). (I have 
> Peter Minuit - if I had not I would require to assert control manually to 
> either buy or steal the land).
> However I quite like the idea that you claim it only if you asserting control 
> (like building an improvement or using the land in the colony).

OK, to clarify fully, for Col1 compatibility we need to support claiming
all the land around a colony (for the colony) by default.  I propose (sigh)
to add a new game option to the colony option group to control this.
Implementation is trivial (one liner in server IGC.buildSettlement).
The backwards compatibility code for a new option is likely longer.  The
option would be disabled in the freecol rules, preserving the existing
behaviour there.

Cheers,
Mike Pope


pgpVGBh4HtyQR.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Headless Horsemen

[Michael T. Pope]

On Wed, 15 Dec 2021 14:48:53 +
Stian Grenborgen  wrote:
> The bug is in SwingGUI.animate where the tile bound is used instead of the 
> proper unit bounds when updating the map. This bug has been in the code for 
> more than a year, but was hidden by the bug triggering a loop of repaints of 
> the entire map.

Confirmed fixed.  The horseman has his head back.

Cheers,
Mike Pope




pgp7YkYiKrkjK.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] La Salle Bonus

[Michael T. Pope]

On Wed, 15 Dec 2021 16:58:05 +0100 (CET)
Stefan Fellner via Freecol-developers
 wrote:
> For founding father La Salle you would usually get the stockade for all 
> colonies reaching population of 3.
> Currently it seems that it only applies to the colonies you are currently 
> owning when la salle joins the congress, plus when you capture a foreign 
> european power's colony.
> 
> In col1, the bonus applied to all colonies as soon as you put the 3rd 
> colonist in.

Are you really certain of that?  We have had contrary reports which is why
laSalle only effects existing colonies ATM.  Let me quote (myself:-) from
the WWC1D? page:

  ...human memory is fallible. Even long term Col1 players have been
  proven wrong. For example, the forums and development list have seen 
  a long argument about food and horses; did the horses eat fish? At one point
  this seemed to be settled in the negative, based on multiple people's 
recollection,
  and a significant amount of work done to the production system to allow this.
  Then a Col1 player stepped up and posted screenshots that finally settled the
  matter in the positive. We really would like to avoid this back-and-forth
  happening again, as developer time is a really scarce resource. So if you know
  the answer to one of the questions, please provide the strongest supporting
  evidence that you can. That is not to discourage adding "I remember..."
  comments, but understand that is much less likely to be convincing. "I just
  played a game with  and it did " is better, and screenshots
  showing the results better still.

> Plus when capturing a foreign colony, which has currently more than 3 pop, 
> and no stockade yet,
> you would first get the colony, then you could reduce pop to below 3 (or 
> abandon it).
> The bonus would only apply after you close the colony after the capture.
> I liked this feature very much in col 1 because you could abandon a potential 
> useless colony.

Ugh.  This is where Col1 has an easier time being monolithic wrt freecol's
client-server structure.  I really do not like adding more message types,
we have quite enough of them already.

I am thinking it would be better to just defer the free build until the
player end of turn.  It gives the colonists time to do the work:-).  We
already send an update at that point, so the change could easily be bundled
in then.

Cheers,
Mike Pope


pgpd3dQCcfrtW.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] [freecol:discussion] Re: Alternate methods of rendering the base terrain

[Michael T. Pope]

> On Sat, 11 Dec 2021 17:44:13 -
> "Stian Grenborgen"  wrote:
> > BTW, the supporting code that made the game run smoothly on a 200MHz CPU 
> > have disappeared. Like fullscreen mode, buffer strategies (page flipping 
> > etc), aggressive clipping and incremental painting.

Ah, I see aggressive clipping is back.  With current trunk, when units are
making animated moves, I am not seeing about 10-20% off the top part
of the image.  This is particularly amusing with the Seasoned Scout, who
is now the Headless Horseman.

Cheers,
Mike Pope


pgpQrDYv03Bwz.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Improve doExecuteGotoOrders

[Michael T. Pope]

On Wed, 15 Dec 2021 00:36:35 +0100 (CET)
Stefan Fellner  wrote:
> I did a bit debugging on goto orders. 
> I attached a save game, hope this works :)

I have the save, and appreciate the test case. However the patch does not
apply to current trunk.

459 Malbec] patch -p1 < ~/improve-goto-orders.patch 
patching file src/net/sf/freecol/client/control/InGameController.java
Hunk #1 FAILED at 121.
Hunk #2 succeeded at 165 (offset -14 lines).
Hunk #3 succeeded at 783 (offset -14 lines).
Hunk #4 succeeded at 818 (offset -14 lines).
Hunk #5 succeeded at 920 (offset -14 lines).
Hunk #6 FAILED at 969.
Hunk #7 succeeded at 1015 (offset -14 lines).
2 out of 7 hunks FAILED -- saving rejects to file 
src/net/sf/freecol/client/control/InGameController.java.rej

I suspect you have been doing a bunch of other incompatible clean ups!

> After that the goto-orders get executed, and the next unit is the privateer 
> up north, which has goto orders going north further.
> They get executed, next unit is a seasoned scout, which goto gets also 
> executed, but then the view changes back to the privateer - which does NOT 
> require attention. 
> Afterwards there would be more goto units, plus the scout really needs 
> attention, has a turn left.

Can not reproduce.  This is what I see:

1. Load game, pioneer selected
2. Hit R to build road, or space, or W
3. Privateer moves
4. Scout moves
5. Colonist moves to Guadeloupe and the colony panel pops up, stopping the
goto moves
6. Hit wait again, more goto moves occur, ending with the scout with 1/4
moves left

> So the problem in the code IMHO is, that the method IGC#moveDirection returns 
> the NO_MORE_MOVES as an illegal move, thus propagating to the 
> movePath/moveToDestination/doExecuteGotoOrders that the unit requires player 
> interaction, thus interrupting the goto unit orders loop and changing the 
> view to the privateer.

That makes sense.  MoveType used to be a lot simpler, and no more moves
was conflated with several other failure conditions.  I worked around the
patch fail, but did not see any difference to the above result.
Nevertheless, I am convinced by the logic, so my lightweight version is
committed (git.6bfc4ff36d).

And with that, consider yourself as having sent sufficient patches.
What is your sourceforge username?  I am only seeing tutanota addresses
from you.

Cheers,
Mike Pope


pgpFW9W7wRlH8.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Question: Building Colony / Claim Land

[Michael T. Pope]

On Tue, 14 Dec 2021 15:56:40 +0100 (CET)
Stefan Fellner  wrote:
> For the "lost" lumber when clearing the forrest:
> Wouldn't it then be the solution to claim the land as soon as the pioneer 
> clears the forrest?

That makes sense, but the right way to resolve such questions is to ask:
  What would Col1 do?
Remember, Col1 incompatibility is considered a bug if the classic ruleset
is selected.

We even have a wiki page for it.
https://sourceforge.net/p/freecol/wiki/What%20Would%20Col1%20Do%3F/

Now I vaguely remember this being discussed when the base lumber add to
colony was implemented.  IIRC (doubtful!) we left it as "no claim -> no
lumber", and once again were reluctant to auto-claim land that the player
had possibly deliberately left unclaimed.

Cheers,
Mike Pope



pgpmY_zYxZWBf.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] TradeRouteInputPanel patch

[Michael T. Pope]

On Tue, 14 Dec 2021 20:24:35 +0100 (CET)
Stefan Fellner  wrote:
> I am not sure what you mean with the graphics files - if you are referring to 
> the icons (cigars_import.png, ...), I have added them on purpose - they are 
> the original icons plus an arrow green/red for the direction.

OK, I misunderstood what they were there for.  However adding specific
modified goods icons is not a good idea as we have multiple sets of
graphics --- mods can install their own versions.  What I think needs to
be done here is to use the currently specified goods icons and either
place arrows next to them or even modify the images on the fly in game ---
see ImageLibrary.getMissionChip for an example where create an image with
a cross in it, and ClassicMapControls for existing arrow resources to
reuse.

> I redesigned the trade route handling to be able to define for each stop what 
> to load and what to unload.

Is that not already clear?  The existing stop shows what leaves the
colony.  Anything not present gets unloaded.  Having to specify things
twice sounds more error prone.

> For loading the export limits are still valid.

If you want to change the logic around goods loading/unloading in
InGameController that is a separate issue.  As far as I can tell, that
part is working fine, albeit the code is complex and not pretty.

> I noticed that you have something called "enhanced trade routes" - can you 
> explain what this is?

If the enhanced trade routes option is enabled you can specify an
*import* level for a goods type, such that the colony/trade-route will try
to retain that many goods of that type, but not more.  This was motivated
by the situation in the late game where your colonies have nothing better
to do than produce artillery, but have insufficient tools production, in
which case players like to send wagons out from the tool-producing
colonies to deliver tools to nearby artillery builders, but only unload
enough tools to so that the colony can complete an artillery unit (40),
retaining any excess tools to take to the next colony on the trade route.

This is still a bit experimental, and adds significant complexity, but was
working in my last large game a while back.  Do you see now why I am wary
of changes to the goods load/unload logic?  Its very easy to break, trust
me on that, I have, repeatedly.
 
> > For example, the modality hackery is potentially useful...
>
> Mm, I can extract that part too; however as this fixes part of the issues 
> with the TRIP

Agreed.  It may fix BR#3209, I am a poor judge of that as I have never
been able to replicate it.  However, the general layout and dragging of
goods and stops around on the TRIP is also broken and thus a separate
issue. What I wonder about the modality problem is why it does not also
show up in other places we do string input, like ChatPanel for example.
Maybe it does.

Looking at the general problem... we already have a nasty hack in
FreeColAction: 

/**
 * Checks if this action should be enabled.
 *
 * @return True if the {@link ClientOptionsDialog}
 * is not visible.
 */
protected boolean shouldBeEnabled() {
return !getGUI().isClientOptionsDialogShowing();
}

Ugh, a special case for one dialog.  Looking at this makes me think what
would be better is if the ActionManager could maintain a list of
active modal panels/dialogs, including the ClientOptionsDialog[1] and
TradeRouteInputPanel.  The panels themselves would register with the
ActionManager when they are displayed, and have a closing callback to
deregister themselves.  That gives us a general mechanism, and the special
case above becomes !getActionManager().modalsRegistered() of the like.
We may even be able to get away with just a reference count
increment/decrement.
 
>>[Unused loggers]
> I tend to disagree - if anyone needs a logger (again) it's easy to add it; 
> why keep unused stuff around?

It is easy to add/remove, but that is still non-zero effort.  Call it
enlightened laziness.  However no one is going to argue over this if you
want to do really low priority work.

> Plus my eclipse shows all unused stuff (e.g. private members) as warnings, 
> and i don't like the source file be yellow blinking :P

This is indeed sometimes useful to show where we have dead code.  I know
we have a few get/set pairs where the setter is not currently used, but if
you see something weighty that is no longer called that is worth fixing.

> > I am curious though, why do you use lambda's in loggger
> > messages?
> >
> Ah, the lambda stuff for loggers - my sonar complains - reason is that if the 
> level is too low, the expression get's only evaluated in case it really needs 
> to log something - this is really only a minor improvement (unless huge 
> amount of logs). Sure, the System.err etc. should be replaced with the 
> loggers (or removed).
> If you want, I could sweep the code base (simple search should locate the few 
> matches, easy fix).

There are a couple 

Re: [Freecol-developers] TradeRouteInputPanel patch

[Michael T. Pope]

On Sun, 12 Dec 2021 21:35:42 +0100 (CET)
Stefan Fellner  wrote:
> I have been working on TradeRouteInputPanel the last week and I got it 
> running now.

Er, the attached patch contains a lot of stuff unrelated to the TRIP.
I am pretty sure the changes to the graphics files are not what you wanted!
I suggest you rebuild the patch, or rather, break it up into multiple
patches, each of which does *one* thing.

For example, the modality hackery is potentially useful, but I am
concerned that isModalFreeColPanelShowing() may turn out to be brittle
(are you *sure* notifyClose covers *all* cases?).  If we need to revert
this change, I would prefer it be able to be done easily without also
reverting the fixes to TRIP.  Similarly, while
InGameController.unloadUnitAtStop is improved by your better variable
names, code cleanups should be independent of functionality work.

Minor points:

- In UnitLabel you are deleting the unused Logger.  Logging comes and
  goes:-), so we have a convention if leaving unused loggers around, they
  usually get used again soon enough.

- In DragListener:
  -System.err.println("DragListener did not recognize:" + comp);
  +logger.log(Level.WARNING, () -> "DragListener did not 
recognize:" + comp);
  Oops, the System.err.println is a leftover debug trace that I forgot to
  remove.  I am curious though, why do you use lambda's in loggger
  messages?

- Apparently you do not share my appreciation for the ternary operator:-)

Cheers,
Mike Pope






pgpm5qcqrxG9t.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Improve unit activation

[Michael T. Pope]

On Mon, 13 Dec 2021 18:05:09 +0100 (CET)
Stefan Fellner via Freecol-developers
 wrote:
> another small quickwin, on unit activation / endofturn handling.
> 
> this two small changes improve the activated units handling considerably - at 
> least for me while playing.

Can you describe test cases where these are improvements?  This has been a
very problematic area.  I want to make sure we are not going back to
something that was a source of complaint.

Wrt the second change, I am wondering if we should use hasTile() rather
than isInEurope() to include the high seas case.

Also, the two changes do distinct things.  We try to fix one thing per
commit, it makes the log history more useful when looking back at changes.

Cheers,
Mike Pope



pgp3oQLdYrKC_.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Another quickfix

[Michael T. Pope]

On Mon, 13 Dec 2021 15:15:03 +0100 (CET)
Stefan Fellner via Freecol-developers
 wrote:
> another quickfix:
> The production labels should only show the "stockValue" aka stockLevel for 
> the ReportClassicColonyPanel.
> Otherwise on the colony screen you get all this production labes like "0 + 
> 12", "0 + 13", "0 + 4", "0 - 3";
> 
> Instead of simply the amount produced or used. ("12", "-3", ...).
> 
> The stockValue is only set at this Report where it makes sense (it displays 
> the current stockLevel plus the added amount). Like for Quebec you got "50 
> (ore) + 13 (per turn)".

Yes, this is annoying.  Applied (git.a9b419aead).

Cheers,
Mike Pope


pgpk8R1RdXxCd.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Question: Building Colony / Claim Land

[Michael T. Pope]

On Mon, 13 Dec 2021 13:11:46 +0100 (CET)
Stefan Fellner via Freecol-developers
 wrote:
> just a question as I noticed this during playing:
> Is this on purpose that when building a colony that the surrounding tiles are 
> not claimed automatically?

Yes.  Some players complained that they did not want to claim certain
tiles for various reasons (most commonly, to avoid annoying nearby
natives).  As there is no mechanism for un-claiming a tile, we made
claiming not happen by default.  AFAICT most players usually just claim all
the free land around a colony shortly after founding it so as to avoid
aggressive other Europeans or wandering natives claiming the land, as they
sometimes do.

> At least the one's which are not owned by another party (indians for the 
> most);
> It occurred to me when clearing a forrest with a pioneer on a then 
> "unclaimed" colony tile would usually add lumber to the colony's stock, which 
> when it is not "claimed" for the settlement does not work (get's lost).

Correct, the lumber would be lost.  I think this is a rare case and easily
avoided.  The alternative would be to add an un-claim land action, which
probably needs a new command and client-server message.  When this was
last discussed we decided not to further clutter the command list with
another very specialized command.

Cheers,
Mike Pope






pgpmwQ02A7he3.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] TradeRouteInputPanel

[Michael T. Pope]

On Sun, 12 Dec 2021 21:35:42 +0100 (CET)
Stefan Fellner  wrote:
> I have been working on TradeRouteInputPanel the last week and I got it 
> running now.

Will have a look soon.  Out of time today.
 
> I changed the layout so that you can now define which goods you want to load 
> and or unload at a particular stop. Also the Drag handling should work fine 
> now (you can drag the goodsTypes from the "AllGoodsPanel" to either the 
> import or export (load/unload) panel. Removing a goods is also possible with 
> right-clicking on the goodstype.

The whole Drag/Drop system in FreeCol is rather weird.  Java now has a
preferred way to do drag/drop which we are only vaguely compatible
with.

> Plus, as you currently are discussing modality, I added a simple solution for 
> disabling the Actions (like Stian was suggesting), while defining an 
> FreeColPanel as "modal" (= quasi modal, actions are disabled while it 
> displays).

Yep, there is functionality there in the ActionManager if you want it.  My
policy has been to minimize modality, so I rarely do.

> Also I fixed at least one bug in the TradeRoute code, when a unit was 
> following a trade route which includes Europa as stop (the trade route was 
> interrupted, cause is a missing "else" in the InGameController). (The missing 
> else was causing the TradeRoute to be interrupted and the vessel stays in 
> Europe).

Excellent!  I think there is a BR that reports this.

> BTW would be great to have a kind of review tool / process in place where we 
> could comment the changes (like when using pull requests / merge requests 
> with a tool, but can also be done with patches).
 
Well, you can create a PR on the github mirror if you prefer that to just
attaching a patch.
 
> And I would really like it if we could maybe schedule a Skype, or Microsoft 
> Teams Meeting (or what else you prefer!) where all active and or interrested 
> devs would meet and discuss the next steps, progress, ...?
> I know already that the current team is spread all across the globe :P
> However this would be very helpful. We need to figure out a good timeslot 
> where it's not maybe 3 A.M. at anyone's time zone :P
> If you are interested, tell me what time zones are to be considered?

Not too keen on *more* meetings.  Do you have a lot of questions?  If
there is one thing I insist on with FreeCol development, it is that we
should be having fun.  Meetings != fun.

> I am in GMT +1 (Vienna).

ACDT == GMT + 1030.  Its a long time since I was in Vienna but we had a
great time there, and Austria generally.  Gday from Australia, that country
you get confused with:-).

> And because I am Austrian guy, my mother tongue is german, I could also walk 
> through the german translations, wording ... 
> Please tell me if this is a possible task! (probably not prio one).

Sign up at translatewiki and see what you can see.  I suspect the DE
translation is pretty good though.  But maybe it is too north-German?

> And what next task is on the line? If nothing special / pressing comes to 
> your mind I will next try to go through my quick noted issue lists / and or 
> BR on the sourceforge BR queue.

That would be my suggestion.  There is a lot to choose from on the SF BR
page!

Cheers,
Mike Pope


pgpmeIfdwD_Bu.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] [freecol:discussion] Re: Alternate methods of rendering the base terrain

[Michael T. Pope]

On Sun, 12 Dec 2021 09:01:05 +
Stian Grenborgen  wrote:
> The point is that we might need to write more automated tests. Writing GUI 
> tests is quite difficult right now since we lack the supporting code.

Quite so.  The test suite has prevented many game logic regressions, and I
have long wished it covered more GUI aspects.

> It would have been great having GUI tests that verify that the number of 
> calls on certain methods (like displayMap) are kept below a threshold.

:-).  displayMap is a beast.

> We could even automatically check for changes in rendering of both maps
> and panels by automatically retrieving an image of the current behavior
> and compare it to a previously retrieved image.

That is partly achievable without GUI twiddling as the intermediate
routines (mostly in ImageLibrary) are suitable for simple unit tests.
Lots of picky work though.  You will notice me not rushing to volunteer.

> The modal JInternalFrame was created when we had synchronous communication 
> between the server and client, with only one game event handled at the time. 
> This avoided having several modal dialogs at the same time (which produces 
> the game hang). The point of making the dialog modal was to prevent changes 
> to the game state before the question was answered.

Which continues to make sense in some places.  By the time I joined
FreeCol I think it had stopped being fully synchronous, possibly to
support multiplayer.  There are some nasty cases with multiplayer, the
worst of which is when two human players are engaged in a diplomatic
trade, because that can go back and forth multiple times until resolved.
(Worse, for a while we had bugs where an AFK human could just hang the
game due to not responding to certain messages (now fixed by use of
TimedSession))  Consider two players concluding a diplomatic trade,
but where one player cunningly removes one of the traded items just before
accepting the trade. If I have done things correctly, that should not
actually work, but that is an example where a modal dialog might be useful
to discourage shenanigans.  (Just checked, NegotiationDialog is modal)

> The problem now is that the server can asynchronously update the client while 
> we are waiting for a response. The question then is why we are still using 
> modal dialogs?

There was some discussion about this a while back.  My view (which
prevailed because I then and went and did the work:-) was that we should
minimize the use of modal dialogs except where needed to maintain Col1
compatibility (IIRC the "goods party" accept/reject is modal).  FTR I
generally dislike modal dialogs --- FreeCol often throws up decisions
where I might want to pull up a colony panel to help work out what to do,
and possibly even fix some issue there, before returning to the decision
dialog.  That said, I am sure there are modal dialogs out there that I
missed... 
 
> What about changing code like this:
> 
> if (gui.confirm("quitDialog.areYouSure.text", "ok", "cancel")) {
> Player player = getMyPlayer();
> if (player == null) { // If no player, must be already logged out
> quit();
> } else {
> getConnectController().requestLogout(LogoutReason.QUIT);
> quit();
> }
> }
> 
> ...into using a callback:
> 
> gui.confirm("quitDialog.areYouSure.text", "ok", "cancel", () -> {
> Player player = getMyPlayer();
> if (player == null) { // If no player, must be already logged out
> quit();
> } else {
> getConnectController().requestLogout(LogoutReason.QUIT);
> quit();
> }
> });

...like that one.  I think I had a policy that game-ending decisions could
stay modal, and just minimized the in-game ones.  Its been a while since
this work was done, probably burned out a bit doing it.  A fair comment
when this was discussed was that the modal code is simpler.

Summary: There are still modal dialogs in FreeCol despite some effort
to the contrary.  We can certainly revisit any remaining ones.

Cheers,
Mike Pope



pgpqgytwlPn5D.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] [freecol:discussion] Re: Alternate methods of rendering the base terrain

[Michael T. Pope]

On Sat, 11 Dec 2021 17:44:13 -
"Stian Grenborgen"  wrote:
> I have fixed several performance issues already. For example, we had a full 
> repaint of the entire map every time the mouse moved 1px! We probably need 
> better testing in order to avoid such problems in the future, as such 
> mistakes are easy to make.

That was probably me earlier this/last year.  There were a whole bunch of
weird cross references between *GUI, Canvas, *Frame, *Viewer.  I tried to
make sure everything low level went through GUI, and higher level
functionality moved to Widgets.  This was worth doing not just for
clarity as it revealed a bunch of dead code, but yeah, probably was not
well tested at the point I had to step back with the job incomplete.
 
> BTW, the supporting code that made the game run smoothly on a 200MHz CPU have 
> disappeared. Like fullscreen mode, buffer strategies (page flipping etc), 
> aggressive clipping and incremental painting.

IIRC full screen mode had some nasty fail on Windows that wintertime
concluded was intractable.  I do not recall what happened with the page
flipping and incremental painting.  I do recall seeing cases where the
clipping was causing broken images but not who/how that was fixed --- my
only involvement was complaining because I was trying to fix a bug in
animation.

> Adding such optimizations back in might be unnecessary, though, as  ten year 
> old hardware can render the entire map in HD several times per second. In 
> addition, we cannot add the original code back in without also converting 
> every JDialog back into a JInternalFrame.

The JDialog problem is my doing, and alas, I have to stand by it.  I can
remind you of the last time we discussed it below.  TLDR: JDialog is a
pain but an unfixable bug that hangs games inside our fake event loop
is worse.

> But then again, I think 250ms latency while moving the map is acceptable. My 
> guess is you want the latency to be lower than 100ms?

250ms for a big map change is fine.  I was seeing really slow single unit
moves (independent of animation) without any map changes.  I just did a
quick test of the current trunk and can not reproduce that ATM.  When I
get a bit more time together I will haul the old machine out of the shed
and see if it is still there, but things are looking hopeful.

Cheers,
Mike Pope

JDialog-is-bad-but-at-least-it-does-not-hang-the-game

From: "Michael T. Pope" 
To: freecol-developers@lists.sourceforge.net
Cc: stian...@student.matnat.uio.no
Subject: Re: [Freecol-developers] Weird full screen problems
Date: Mon, 27 Jan 2014 22:31:39 +1030
Organization: FESOSA

On Fri, 24 Jan 2014 20:08:09 +0100
"Stian Grenborgen"  wrote:
> Another problem with using JDialog is that they don't mix well with
> JInternalFrame. Layering, focus etc is handled by the windowing system for
> the former, while JDesktopPane handles it for the latter. That's why the
> ChooseFoundingFatherDialog is always in front of the Colopedia help panel
> you get when clicking the "help" button, for example.  

True, but this is new code, and there is a routine in place to try to
place both dialogs and frames such as to avoid overlap.  I do not know why
it is not working in this case, but this looks like a mere bug, not a
fundamental showstopper.

Now I cheerfully concede not really understanding Swing et al.  What I do
understand is FreeCol bug reports.  Here is the justification for the
JDialogs:

- Some dialogs in FreeCol need to be modal, some need to be non-modal.

- We had a trick for non-modal dialogs the centered around reimplementing
  an event loop handler inside FreeColDialog.getResponse.  This was very
  clever, but outdated (did we really want to track the Java event loop
  code? no one had ever bothered) and brittle --- for unknown reasons it
  was occasionally possible to get stuck in the getResponse handler, and as
  such caused at least six, and possibly as high as twelve serious FreeCol
  bugs (we will never know, it was a client-side effect and did not
  reproduce easily, so several reports are suggestive but frustratingly
  inconclusive).

- When a getResponse bug hit, there was nothing you could do but kill
  freecol and restart from the previous save.  That is serious.

- JDialog is a standard way to provide a modal or non-modal dialog.

I consider that a strong case for killing getResponse.  Even if it were
true that JDialogs are causing windowing misbehaviour, that is nowhere
near a game-killer bug.


> Considering the other problems with dialogs appearing behind each other:
> It should be possible just to grab the panel that is blocking the other,
> and click on the panel behind. Unless you are clicking on a component (or
> there are additional JPanels intercepting the mouse click), this should
> make the panel you click appear in front. Isn't this working?  

In every case of overlap

Re: [Freecol-developers] Hello FreeCol Team!

[Michael T. Pope]

On Sun, 5 Dec 2021 04:01:04 +
Jonathan Aquilina  wrote:
> I noticed you mention the ram issues below. Can I make a suggestion and do 
> maybe like mine craft does. If you have mod's for example you can through the 
> curse launcher remove the system allocated amount of ram and manually 
> allocate an amount lets say 8 or 9 gb of ram if you know it needs it. Maybe a 
> manual specification of ram allocation might be advantageous and help?

FreeCol already sets its own limits on memory allocation.  The slow down
*may* be due to too much garbage collector activity within the memory we
allocate, or perhaps a secondary effect through the operating system
generally, or just that the amount is too small.  Again, this is all
speculation.  I need to reproduce the problem and measure relevant values.

Thanks for the suggestion, but I have no idea what the "curse launcher"
is, and doubt it is something I can use on linux.

Cheers,
Mike Pope


pgpqP8fZ0_2jj.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Hello FreeCol Team!

[Michael T. Pope]

On Sat, 4 Dec 2021 11:25:52 +
Stian Grenborgen  wrote:
> > Activity has been weak this year... here is to a better 2022.
> 
> I will definitely try to help make that dream come true ;-)
> 
> Hoping you also have more time to spend in 2022, Mike!

Well, its a low bar to jump:-)
 
> > I doubt anyone is opposed to useful code refactorings, but we are *way*
> > overdue to make a release, so the priority should be fix bugs/stabilize
> > ATM.
> 
> What are the bugs you consider to be blockers?

The worst problem is that I am seeing severe slow down in large games.
Or rather I was, I need to run my performance tests again following a
computer upgrade.  I suspect replacing an 8 year old machine including
quadrupling the RAM may have helped, but there we already control the
java memory allocation so in theory it should not.  I should stop
speculating and get the numbers.

I will look through the bug list and follow up on other potential
blockers. I posted on the subject a while back.

> ...or should I just keep fixing stuff I encounter while making the game work 
> better on 4K?

One of the top suspects for the slow down is the main map redrawing
routines, so I am delighted to see you trying to untangle any part of the
graphics.  Certainly I think "broken on 4K" would count as a blocker.
By all means though, work on what you think is best/interesting/fun.  I am
reluctant to do more than suggest what volunteer developers should do, let
alone the project founder:-).

Cheers,
Mike Pope



pgpd8mSmtdA2t.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Hello FreeCol Team!

[Michael T. Pope]

On Thu, 2 Dec 2021 14:46:44 +0100 (CET)
Stefan Fellner via Freecol-developers
 wrote:
> I have been watching the project quite some time and I want to participate in 
> the development process, if you guys are still activly developing.

Activity has been weak this year... here is to a better 2022.

> I can either share the issue list, or I think you are using the SF bug 
> reporting, I may also browse through that list, and add or update from my 
> list if you wish?

Please merge with the SF bug list.  One issue per report.  We get a lot of
duplicates and it is best to track bugs in one place.
 
> What do you think about some refactorings, and or introducing some helping 
> libs - like lombok?
> I would also fix all "potential NPE" stuff, and remove redundant null-checks.

I doubt anyone is opposed to useful code refactorings, but we are *way*
overdue to make a release, so the priority should be fix bugs/stabilize
ATM.

> I cloned the SF git master - how is the process here to open a merge request 
> / pull request?

Our usual procedure with new contributors is a accept patches on this
list, and after a (very small:-) number of useful patches your SF account
is granted write access.  Here is a suggestion --- I was trying to fix the
TradeRouteInputPanel a while back but ran out of time --- how about you
have a look at that?  It will be hard to make it worse than the broken
state I left it in.
 
> Usually i would create a branch and open a MR or PR in gitlab / bitbucket. Is 
> this also the case for SF?

SF does not have MR/PRs.

> If you want to know anything more about me - just ask :)

Delighted to have an experienced Java developer interested in FreeCol.

Cheers,
Mike Pope


pgp4KdT3mi4kD.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Nightly Builds broken

[Michael T. Pope]

On Sun, 30 May 2021 08:46:33 +0200
win...@genial.ms wrote:
> I just found out while trying to trigger a new nightly release
> that there are major changes between Github and travis-ci.org
> and when clicking the build button on https://github.com/FreeCol/freecol
> there is a warning they shut down travis-ci.org and want people to
> sign up for travis-ci.com .
> Additionally, I found this blog post:
> https://blog.travis-ci.com/2021-02-22-switch
> 
> It seems it already stopped working between 2021-04-04 and 2021-04-18,
> as Mike had triggered a nightly release on that day and it did not build.
> 
> Atm, I'm not sure how we should fix this?

Likewise.  Who does?
 
> As I'm a bit out of the loop, I'm not sure which issues are still blocking
> a real release on SF?

The performance bug is still lurking and I have made no progress there
lately.  The trade route panel is borken and proving annoying, I have had
three goes at fixing it but last time I concluded that the whole
drag-and-drop system needed work:-(.  However, it might well be
time to do 0.12.0-alpha1.

Cheers,
Mike Pope



pgpJ2Hi9pM0I3.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

[Freecol-developers] diverged commits

[Michael T. Pope]

Caleb, why are you committing to github only?  The main branch is still on
sourceforge, github is only supposed to mirror it.  The repos are now
diverged and include duplicate work (the copyright years) which may be
annoying to untangle.

Cheers,
Mike Pope


pgps5uO9wZBQv.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] FreeCol: Contribute Programming and Content Writing

[Michael T. Pope]

On Wed, 5 Aug 2020 17:17:01 -0400
"Mr. Pavel Koterniak"  wrote:
> (In regards to Indians and Indian Report)
> 1) Add the amount (number) of muskets and horse herds each tribe has.

Where did this information appear in Col1?  I have always been dubious
about for example revealing that information on the native settlement
popup, because unless you gave the natives the required horses and
muskets or have a friendly missionary in the settlement, there is no
obvious way you can tell the exact composition of their military.
Currently you can not even tell the settlement population[1].  OTOH, if you
want to add that information at the tribe level in the aggregated native
relations report, that is more defensible.   We have a lot of complaints,
which I agree with, that the natives are too weak.

> 3) I looked through the variety of units and didn't see Warriors (Braves
> armed with muskets), Mounted Braves or Mounted Warriors.

You are right that there are no such dedicated unit types.  But there
certainly are Mounted Braves et al.  You need to understand Role.java.

Cheers,
Mike Pope

[1] Did Col1 reveal native settlement population?


pgpXFfqv5YTlh.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

[Freecol-developers] understanding MapViewer

[Michael T. Pope]

I am trying to understand and document the map drawing logic in MapViewer.
There are quite a few magic variables, which I think fit into three
categories:

1. Dependent on map scale:  e.g. tileHeight et al
   I think I understand these, and have collected their maintenance
   into updateScaledVariables()
  
2. Dependent on map size (and scale):  e.g. topSpace
   I do not understand these, but can see the dependency and have
   collected their maintenance into updateSizeVariables()
  
3. Dependent on map position:  e.g. bottomRows
   I have not tried to understand these yet

Looking at category 2 then:

(leftSpace, topSpace) appears to tbe the pixel coordinate of the upper left
corner of a tile if it were to be drawn in the center of the
map-window.  For some reason there is also a rightSpace equal to
leftSpace, but no bottomSpace.  topRows is possibly the "number of rows
that will be drawn above the center tile" of the comment, and there is
again a bottomRows equal to topRows.  TopRows is roughly topSpace divided
by half the tile height.  One would imagine there would be corresponding
left and right variables, but that happens in getLeft/RightColumns() where
leftSpace is divided by the full tile width, unlike for topRows.  In all
cases there are magic +/-1 factors added, and a mysterious magic 32 in a
test:

  (leftSpace % tileWidth) > 32

Pretty much every sentence in the above paragraph should be read with
a ", but why?" on the end:-).  I am posting this message in the hope that
someone who has worked on this code in the past has some wisdom to
pass on.  Preferrably with a little more detail than "it has to do
that so the map-projection works".

Cheers,
Mike Pope


pgp4kACR0blpx.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] not dead yet

[Michael T. Pope]

On Sun, 19 Jul 2020 13:20:06 + (UTC)
D Blakeley via Freecol-developers
 wrote:
> In regards to the SF forum activity could Mike, Winter or anyone else who has 
> good technical knowledge of the game do a quick pass on the recent threads?

I have read everything.  I always do.  But I prioritize ruthlessly.
Generally, unless I have a bit of time or a current interest in an area, I
do not chase down random complaints on forums. They are just too hard to
track, and so often are way short of reproducible.  Right now I am deep
into untangling the GUI and finally working out where the graphics
slowdown[1] is (~50 commits last week, that was a good one:-).

That said, there is a 100% infallible way to get my prompt attention.  All
it takes is a good bug report.  OTOH, guess how much fun it is to be the
guy on the forum who is always saying "make a bug report".  Been there,
still there from time to time, not thrilled with that.

Also, what is said on the forums does influence what I look at next.
Multiplayer is on the list to look at, but it is a tricky area that
requires me to revive a bunch of sleeping neurons, and hard to test. I
know it works for me on my LAN, and all I have heard to the contrary has
not got above "it does not work".

Now if only we had an enthusiastic contributor who was clearly a lot more
into social media and could nudge some of the unfocused venting into
detailed bug reports.  Heh, notice a pattern with what I say whenever
asked to do something?:-)

Cheers,
Mike Pope


pgpgbXvsoezHj.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

[Freecol-developers] InfoPanel struggle

[Michael T. Pope]

The InfoPanel (bottom right corner:-) has been a longstanding wart.  I
had time today to hack at it, and just committed a simplification that
fixes some mistakes I have added over the years.  I am now hopeful the
empty InfoPanel bugs have been tracked down.  However... I did mess with
the placement and sizing of the panel contents, and it probably looks a
bit wonky.  If someone with a better eye than I is interested, the magic
numbers used in setSize and setLocation in InfoPanel.setPanel could use
some attention.

Cheers,
Mike Pope
-- 
The .signature hits!  You have mail.


pgpfEfMwmozQx.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Java version

[Michael T. Pope]

On Tue, 16 Jun 2020 08:50:48 +0200
Jonathan Aquilina  wrote:
> I was under the impression and it was an incorrect one that freecol was
> built on the oracle version of java. If its based on openjdk no concern
> here.

The FreeCol project does not require a specific Java implementation.  If
someone wants to build it on openjdk, oracle Java, or
shark-mounted-laser Java that is fine.  We do specify a minimum Java
language version, because we are primarily concerned with making code +
artwork + game resources rather than packaging.

That said, we have traditionally distributed freecol packaged for various
platforms from the website as a convenience.  The .jar files there are
built with whatever-the-release-manager-is-using Java.  When I am the
release manager that has been openjdk, because that is conveniently
installed on my main development machine.  Perhaps it was oracle Java in
the past, I do not know.  I am pretty sure we have people running our .jar
or derivatives on non-openjdk run time environments, which is good.

Cheers,
Mike Pope



pgpPqkTEREBo2.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

[Freecol-developers] Java version

[Michael T. Pope]

Quick heads up.  According to wikipedia at least, Java 8 is scheduled to
be updated for the last time in December this year, so we should probably
move to Java 11 (the next one that has long term support) around then.

The good news is that today while trying to find an out of memory bug
when testing large maps, I built FreeCol on an Ubuntu 18.04 box where Java
11 was installed by default.  There were three small problems, now fixed.
So I anticipate that the move will be trouble free.

Cheers,
Mike Pope


pgpaMk2860UZR.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] not dead yet

[Michael T. Pope]

On Sun, 31 May 2020 16:10:47 + (UTC)
D Blakeley  wrote:
> [lots of stuff about maps]

The maps are in (git.5b617fe).  Many thanks to Blake for a lot of
wrangling.

Cheers,
Mike Pope


pgpf5hBVilmju.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] not dead yet

[Michael T. Pope]

OK, bit more time to go through the mail.

> 2. As for Rafael's changes and storing Author and description in the map 
> file...

The issue here is that we can not store the description in the map
iteself because it needs to be translated.  The author is fine.
Currently we effectively do neither.  Rafaels patch does both.  If we
can get the author into the map, a bunch of the stuff you have been
wrangling in the strings file can go from:

map.Africa=Large Africa by J.Bloggs

to

map.Africa=Large Africa by %author%

which does not help your work much now, but is more maintainable.
There would have to be code support of course to pull in the %author%,
but that is straightforward.

I have a note on the todo list to think more about the whole
translation setup, but that is post-release.  We already have extra
standalone FreeColMessages.properties files in the mods, which are
currently not getting translated AFAICT.  If we can fix that, we can
probably handle having similar files in the .fsm map bundles.  That
would probably be a better design than having the above map.
entries in the master strings file.  The major concern with any change
to how we do translations is to not mess with the volunteer
translators.  Keeping things easy for them is mandatory.

> 4. Regarding Sourceforge improvements...

Yeah, I suspect front page hackery may be locked to the main project
admins, which means I probably have to do it.  The offer is: if I see
messages here from at least two regulars saying that  is ready to
go as a replacement for {SF front page, screenshot, whatever} I will
make time to work out what has to be done.  Time is the issue, I never
used to do anything with SF admin, and it always takes me a while to
work out what does what.

> 6. As discussed in past emails I overhauled your old FreeCol ModDB page

...another thing I had never sighted.  No idea who originally created
it.  If it needs an "official" owner, you are it Blake.

> 7. [Social]

Please do not interpret my absence from the facebook bit as disapproval.
I just do not use it, deliberately.  Getting time to work on FreeCol
is hard enough lately, I do not need more time sinks.  Perhaps I will
look at the discord channel... eventually.  Nevertheless, thanks for
pushing this stuff forward.

Cheers,
Mike Pope


pgpjpgfkeWWD9.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] not dead yet

[Michael T. Pope]

Quick reply.  I have dealt with #1 and commented on #3, but it is time to
go to work.

Cheers,
Mike Pope


pgpgCc_t83Bpa.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

[Freecol-developers] not dead yet

[Michael T. Pope]

Productive (for freecol) day for the first time this month.  I have fixed
merged or at least reviewed all the new bugs since I last had a chance to
look, all the github issues, and all the github merge requests.  As usual
there are cases where we need more information, but hopefully the bad ones
like the native settlement name fail are sorted.

Outstanding is Rafael Oliviera's patch allowing the author and description
to be added to the map.  I could not accept the patch as is, and commented
that the author could probably be an optional field in Map, but the
description needs to be translatable.  I believe this can work with the
wrangling Blake has been doing... so how is it going Blake?

Hope everyone is well, and have stabilized their work arrangements now.

Cheers,
Mike Pope


pgpV0PYgZig7y.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] New pull requests

[Michael T. Pope]

> Just letting you know the good news that a number of different people are 
> making contributions to FreeCol on github...

Quite so.  Pity they are a bit down the list.  I was away last week, and
am now stuck at github issue#32 which is proving to be a PITA, and there is
a new sourceforge bug to look at... after that I plan to deal with the more
problematic pull requests...

> Mine PR has been sitting there for weeks too...

...like yours:-).  Your map reworking has problems...  Lets try again.

1. The name of the map file is *not* what is supposed to be displayed on
the map selection panel.  Yes, we want to credit the authors, but
crufting them into the file name is not how to do it.  Worse yet,
renaming the existing map files is breaking the test suite, which is why
the github page for your PR is showing failed checks.

2. File names with spaces tend to cause breakage in the build scripts,
please avoid them.

3. The string we display under the map thumbnail comes from the
strings database.  This is a file called "FreeColMessages.properties"
which is in the strings directory, right next to the maps directory you
have been hacking around in.  It is a plain old text file, and contains
lines like "freecol.map.Australia=Australia".  To credit someone, you
would change that, for example, to
"freecol.map.Australia=Australia by Drongo Bruce"

4. For every file in the maps directory, you need a line in the properties
file.  The left hand side *must* have the freecol.map. prefix, after
which is the *file name* without the .fsm extension.  Once again, no
spaces in the file name as that can stuff up the routines that read the
properties file.

5. If you do *not* do this, freecol goes through the map directory, finds a
file called foo.fsm, tries to look in the strings database for a key of
freecol.map.foo, fails to find it, and defaults to just displaying the key
freecol.map.foo.  Which is what you were complaining about in
https://sourceforge.net/p/freecol/bugs/3182/

6. Yes I read your "but hunting down master translation stuff somewhere in
something.. umm yeah.. I got no idea sorry." response in that bug.  Humour
me, eh?  I am stretched pretty thin here, and really appreciate it when
people work stuff out from what I admit is a terse explanation on my part.
Hopefully this was a bit clearer and/or enough detail to get things moving
again?

Cheers,
Mike Pope


pgpYvcmV5Pazo.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

[Freecol-developers] Testing Spanish Succession

[Michael T. Pope]

Does anyone have a saved game just prior to the Spanish Succession event?
I am trying to reproduce an associated bug, but my test game is so old
(started in 0.10.0!) that I have to run a patched version of trunk to get
it to even load.  Something more recent would be more useful.

Cheers,
Mike Pope


pgpmRzwvAeMZU.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] FreeCol XXE Vulnerability

[Michael T. Pope]

On Tue, 14 Jan 2020 09:15:42 +0100
win...@genial.ms wrote:
> As far as the discussion was gone, which we had about doing
> 0.12.0 soon, is there any annoying+blocking bugs left?

I am working through the github issues.  I want to at least look at them
before we have an semi-official-tentative-alpha release.

> - Is the fix to the returning from Europe bug sufficient
> or is it necessary to do something for the very few cases
> where in a save the ship was already in Europe?

I have not properly understood that one yet.

> - I'd like to see https://github.com/FreeCol/freecol/issues/15
> fixed, cause it is irritating to play like that

You are in luck, I got to that one today: git.e7a40b4.  It was indeed very
annoying, and alas a result of me having to stop work mid-project.

Cheers,
Mike Pope


pgpmzoOeN2CrC.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

[Freecol-developers] BR#3142 Scout can not enter enemy city to spy

[Michael T. Pope]

I am having no luck reproducing this.  Anyone else seeing spying failure?
I just added a log message to indicate that the server has seen the
request, so that should help bisect the problem.

Cheers,
Mike Pope


pgpY0K9T7Bno7.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Website fixes

[Michael T. Pope]

On Thu, 2 Jan 2020 23:19:14 +0100
win...@genial.ms wrote:
> I was anticipating of moving the website over to GitHub someday, but it's 
> kinda surprising you'd like to move over the domain so fast when the other 
> stuff is still on SF? 

Quite so.  I wish people who want to move stuff around would
at the very least come up with a plan that includes the hard
problems, like how to move the forums.  The website is easy.

> Would it be easier to get https support for the freecol.org domain on GitHub?

That is a timely remark.  Yesterday while I was trying to work out who has
permission to update the SF website I came across something new[1]:

Your website is currently hosted at
http://freecol.sourceforge.net with PHP 5.4

To update to https://freecol.sourceforge.io and PHP 7.x, click 
the button below.
There will be a small delay for it to take effect. You may 
switch back if needed.

I propose to click the button.  There is also some interesting stuff about
github connections which I have yet to read.  More soon.


And in the special D Blakeley section:-):  Blake, yahoo is not
accepting mail from my ISP, who are sending me messages like:

This is an automatically generated Delivery Status Notification.

THIS IS A WARNING MESSAGE ONLY.

YOU DO NOT NEED TO RESEND YOUR MESSAGE.

Delivery to the following recipients has been delayed.

  

The reason for the problem:
4.3.2 - Not accepting messages at this time 421-'4.7.0 [TSS04] Messages 
from 150.101.137.19 temporarily deferred due to user complaints - 4.16.55.1; 
see https://help.yahoo.com/kb/postmaster/SLN3434.html'

Given that I am with internode who have won a bunch of customer service
awards, and you are with yahoo, who... hasn't, I am guessing the problem
is at your end.  Now we just need someone to quote this email so Blake sees it.

Cheers,
Mike Pope

[1] "New" as in "added since I last looked around about a year ago"


pgpX79d5o_93I.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Website fixes

[Michael T. Pope]

>>[Jonathan]
>> thing is the community will need someone versed in website coding and 
>>styling if that person leaves there is a bit of an issue there.

This has always been the case.

>[D Blakeley]
> That's exactly what worries me. This Jekyll thing sounds like its not going 
> to be something the average guy (eg me) can use...

AFAICT if you want to write content, then use of Jekyll means you have to
write in Markdown.  You are going to have to be pretty average to find
Markdown a high bar:-).

If you want to build the site you will need a working Jekyll install,
which might be trickier.

The actual upload to SF is straightforward, but you need permission.  I
have looked at the SF permissions, and remain confused.  However if
winterime is able to upload (which is good) David should have the same
permissions.  David, have you tried:

  sftp $USERNAME,free...@web.sf.net

with your SF username and credentials?


Anyway... generally with respect to the website I really do not have a
many strong opinion about how or what it looks like.  I am delighted
people are working on it again, and I am trying to help but mostly keep
out of the way.  What I do care about is that it be low maintenance
because as Jonathan rightly reminds us above, people leave.  However I do
not share Jonathan's enthusiasm for Wordpress... one CMS debacle was
enough.

Cheers,
Mike Pope




pgpxLdgElOfDe.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Website fixes

[Michael T. Pope]

On Sun, 29 Dec 2019 06:15:09 +0100
Jonathan Aquilina  wrote:
> This is really up to those in charge to take the decision but the hosting
> offer still stands. SF can be a huge pain in the rump though.

I too appreciate the offer, but I am reluctant to split the project over
yet more sites.  SF has its disadvantages, but we have no replacement for
the SF forums.  Meanwhile I am hopeful the new static generator will reduce
the maintenance pain in the long term.

Apologies for the slow reply, sorting out the bug list and mail backlog is
taking me a while.

Cheers,
Mike Pope



pgpNPy2zBJvJF.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] FreeCol XXE Vulnerability

[Michael T. Pope]

On Tue, 31 Dec 2019 02:06:21 -0800
David Lewis  wrote:
> I think we might be okay to start releasing RC versions of 0.12 right away,
> since "0.x" implies beta, we don't need to necessarily support the 0.11
> line, and thus don't need to worry about backporting fixes, so long as we
> release an update that contains the fixes that folks can upgrade to.

I have been working through the bug list and while there are indeed new
annoying open issues, perhaps the CVE-fix is enough reason to just forge
ahead.

>[wintertime, regarding the news item]
> Should it be mentioned that even older versions are affected and which?

AFAICT the dodgy Java call has been in use since at least 0.10.0.  Ironically,
there used to be a lot more of them!  I mentioned 0.11.6 explicitly because that
the only version we are really supporting at this point (i.e. if you report a
bug in earlier FreeCol the first thing I want to know is if you have tried the
current release).  However feel free to say something like "All supported
FreeCol releases prior to 20191227" or thereabouts.

> When should people upgrade?

Well I always tell people who just want to play FreeCol to use the latest
stable release, and I would continue to say that.  However that is just my
opinion.  Do we even want to make an Official Recommendation?

Cheers,
Mike Pope




pgpmV2hBih2nV.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] FreeCol website upload

[Michael T. Pope]

On Tue, 31 Dec 2019 11:12:04 +0100
win...@genial.ms wrote:
> The usual Ruby way is to do:
> $ gem update jekyll
> I think, your Linux distribution may want you to get it from their
> package manager / repository

Quite so.  AFAICT jekyll 4 has been packaged for the next Fedora release
so I can probably pull it in early with a little hackery.  Or just wait
a few months:-).

> Ok, nice. I'll continue with it for a bit on my repo. You all can take
> a look on https://github.com/wintertime/FreeCol/tree/jekyll and when
> it is ready we put it in main and compile/upload.

I am sufficiently convinced this is an improvement, please push forward
as you see fit.

Cheers,
Mike Pope


pgpibJZU9Pp35.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] FreeCol XXE Vulnerability

[Michael T. Pope]

Here is some text (markdown) for the website wranglers to consider adding
as a news item.  I made a lame effort to build a proof-of-concept exploit,
but lost interest fairly quickly.  I remain unconvinced we need to backport
to 0.11.6 and release 0.11.7 given the low level of threat posed, but am
interested in other opinions (and/or volunteers).

Cheers,
Mike Pope

-
FreeCol 0.11.6 and subsequent development versions up to 20191227 are
subject to an XML External Entity parsing bug, due to use of a
vulnerable Java library, as detailed in
[CVE-2018-1000825](https://www.cvedetails.com/cve/CVE-2018-1000825/).

According to the CVE the bug can lead to disclosure of confidential
data, denial of service, SSRF, or port scanning, albeit with limited
attacker control.

Exploiting the bug requires convincing a player to load a specially
crafted FreeCol save game, either directly or by joining a hostile
FreeCol server.

The FreeCol team are unaware of any actual cases of this bug being
exploited.  It is fixed in the [nightly 
releases](https://github.com/FreeCol/freecol/releases)
from 20191229 onward.


pgpkK01Pu1gRl.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] FreeCol website upload

[Michael T. Pope]

On Mon, 30 Dec 2019 09:55:59 +0100
"Sebastian Zhorel"  wrote:
> 40°C is like hottest summer temperature in Germany. I'd feel like dieing,
> because nowhere except some office buildings anyone got air condition.
> I guess, it gets even worse down under. ;)

Yeah, the 45C day a couple of weeks back was pretty harsh.  Hope you get
some snow.

> Sorry, I'm late. :o Merry Christmas and Happy New Year!

And indeed to you too.  I was cutting our Christmas tree on the afternoon
of the 23rd so I will not be criticizing anyone for lateness.

> > OK, so www.freecol.org/docs/Freecol.{html,pdf} were broken, and should
> > be fixed now.  Are there more?
>
> I just tried, and there is 0.11.3 version on server.

Yes, I only fixed the git master, I have not done the upload.

>>[Jekyll]
>...git-cloning...
> $ cd www.freecol.org
> $ jekyll build

1132 Malbec] cd www.freecol.org/
1133 Malbec] jekyll build
Configuration file: none
Source: /home/mpope/src/fc/FreeCol/www.freecol.org
   Destination: /home/mpope/src/fc/FreeCol/www.freecol.org/_site
 Incremental build: disabled. Enable with --incremental
  Generating... 
done in 0.645 seconds.
 Auto-regeneration: disabled. Use --watch to enable.
1134 Malbec] ruby -v
ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-linux]
1135 Malbec] jekyll -v
jekyll 3.8.6

Not quite what you wanted.  However I looked at the contents of _site
and could not see any obvious failure.  So it looks like it worked for me.

As usual I am wary of more dependencies, but a static generator is
probably the best tradeoff for us now, and I think markdown is a good
compromise.  So I think this is looking promising. 

Cheers,
Mike Pope


pgptUHfL4GBkO.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] FreeCol XXE Vulnerability

[Michael T. Pope]

On Sat, 28 Dec 2019 01:02:33 +0100
"Sebastian Zhorel"  wrote:
> Maybe it'd be faster to just backport the patch to stable branch and
> throw out 0.11.7, to skip doing long investigations?

That is an option, albeit a heavyweight one.  I have forwarded this to
the development list to solicit more opinion.  Call me lazy, but an
announcement that says "beware of running games from untrusted sources or
servers" is probably enough.

> for people stuck with the old version (I wish we could just make the
> 0.12.0 release from master, but I guess that's still months away).

I am reviewing the bug list right now.  There is still a nasty performance
problem on large games, but we were in decent shape for an alpha release
back when I had to step away earlier this year.

Cheers,
Mike Pope


pgpObP7u2JZeg.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Website fixes

[Michael T. Pope]

On Mon, 23 Dec 2019 14:38:17 +0100
win...@genial.ms wrote:
> I pretty much do not even know what is available to us on the server.
> I only remember from reading previous discussions on mailing list, it is not 
> wanted to upload
> any CMS or maybe even any server side programs at all, anymore, for security 
> reasons.

IIRC we used to have a Drupal setup.  Eventually it was exploited
(yay PHP:-P).  Due to no one being interested in fixing it or committing to
long term maintenance of a CMS, I argued that a simple static site made
most sense given our resources.  Caleb did good work on the content,
including ripping out a lot of CMS-isms.  My involvement has never been
more than trying to work out how to add the release information to the
CMS, and subsequently to doing uploads.  So I am pretty pleased that you
guys are able to put in some effort improving the website.  It is long
neglected.

I will see if I can do a blanket upload from sf git shortly.  I think the
upload script is "clever" and tries to upload what has changed.  It may
well be being too clever.

Cheers,
Mike Pope


pgpoRFuCeCHlv.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Project looks abandoned due to presentation issues

[Michael T. Pope]

On Mon, 2 Dec 2019 14:14:36 +0100
win...@genial.ms wrote:
> I'm not sure if there is a script updating the website from git or if Mike 
> has to
> upload it manually? This would be good to know beforehand.

ATM there is a dodgy script (bin/website.sh) but I am not sure what
the permission required is.  I know it works for me.


On Thu, 5 Dec 2019 00:41:51 -0800
David Lewis  wrote:
> I would like to add all of the FreeCol contributors to the project space on
> Github...

IIRC my github username is mpope...@gmail.com.  HTH.


On Fri, 6 Dec 2019 10:49:06 + (UTC)
D Blakeley via Freecol-developers
 wrote:
> I think that sounds bloody wonderful David, but I'm not a member of the team 
> haha!

You might be surprised how low the bar is there.  Currently anyone with
time is better qualified than I.


>[git commits from wintertime and blake]

bin/website.sh does not handle a multiple commit backlog very well,
but I think I have worked around it, so the website should be updated.


Cheers,
Mike Pope


pgppD6j8x_izD.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Project looks abandoned due to presentation issues

[Michael T. Pope]

On Mon, 2 Dec 2019 14:14:36 +0100
win...@genial.ms wrote:
> sorry I could not participate much last years, cause I had to concentrate on 
> other things.
> I still tried to keep up with reading all new messages.
> I'm also kind of sad that no new release got out meanwhile, as last news I 
> read on it
> there were only 2 bugs blocking it.

I regret this too.  My involvement has been cut drastically due to a
family health issue.  I remain hopeful to get back to FreeCol after
Christmas.

> I found this news item: 
> https://sourceforge.net/p/freecol/mailman/message/36041651/
> I wonder why it was never added to the website, to tell about the nightlies?
> If Mike+David are ok with it being added THAT MUCH too late, I could add it 
> to the website
> code in git soon? I'd also add the link to the front page.
> Additionally/Instead, maybe another news item about how work the 0.12.0 
> release is going
> would be nice. I'd need a few lines of text for that though.

Are the nightly builds still running?  David has been quiet too.

Cheers,
Mike Pope


pgpfn2b2gcdXX.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Strange getSurroundingTiles behaviour

[Michael T. Pope]

On Tue, 8 Jan 2019 21:10:18 +0100
Sébastien Fauvel  wrote:
> I try to understand application to give some help if I can.
> I found a strange behviour in MapTest (method testGetSurroundingTiles).

Look at Direction.java for clarification, although ISTR there are
better commented places which I can not bring to mind.

The way the grid is laid out is not something I can comment on with any
confidence as it was in place from years before I joined the project.  I
certainly recall finding it surprising initially, however it clearly
works, and knowing nothing much about map projections I am happy to credit
the elder developers with knowing what they were doing.

Generally I think it is best not to have to think about the map
embedding detail, and use abstractions like getSurroundingTiles() that
hide that from you.

Cheers,
Mike Pope


pgpQu8icnsovG.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

[Freecol-developers] performance

[Michael T. Pope]

Just to keep everyone in the loop, I have been fairly distracted lately,
but have a bunch of experimental performance improvements undergoing
benchmarking.  We have a serious problem with large games where I am
seeing major slowdowns, but puzzlingly its not so much with the gameplay,
but with the basic graphical operations --- just bringing up a popup menu
for example.  Profiling and benchmarking continues.

The bug list is little changed since last time I commented.  (Yes, Marcin,
I will be fixing your new bug shortly:-).

Cheers,
Mike Pope


pgpGrMcf1HBDD.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] French translation

[Michael T. Pope]

On Thu, 7 Dec 2017 17:03:24 +
Avice Robitaille  wrote:
> I was doing some research and when I visited your excellent page 
> http://www.freecol.org/about.html, I noticed it was not translated into 
> French.
> 
> I am a native French speaker with a Bachelor in Foreign Languages and I am 
> also a translator.
> 
> I translate any text from English to perfect French. I have worked as a 
> freelance translator for over 7 years now and have meticulously translated 
> among other things: Scientific papers, business documents, website content, 
> instructions, articles and literary texts….
> 
> If you want, I can translate your page for free with the same content, but 
> also by keeping its form and its links.
> 
> Let me know if you are interested by my offer and, in some weeks, I will send 
> you the URL where the translation will be available.

We have a deliberately very simple website so it is unlikely that we
can do the auto-language-selection trick seen in other places.  However we
can certainly put a link to a French translation of about.html somewhere
prominent on about.html.

What do you think Caleb?

Cheers,
Mike Pope


pgpmBp6fw_wgE.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

[Freecol-developers] 0.12.0, bug tracker update/release status/alpha = go for it

[Michael T. Pope]

On Thu, 14 Dec 2017 18:58:47 +1030
"Michael T. Pope" <mp...@computer.org> wrote:
> Very serious, alpha-release blocking:
> BR#3121 Cant attack shipt
> Desynchronization.  Must fix, working on catching it now.

Marcin came through with a test case, and I am hopeful this is now fixed.
Hooray!  

I have been play testing quite a bit since Christmas, and while I have
found bugs and fixed them, the only thing that is really annoying is that
the GUI is weirdly slow at times --- just simple things like popping up
a yes/no dialog take seconds when they should be near instantaneous.
This seems to be worse with large games, but even small ones show the 
effect.  This may well be BR#3102.  I did the obvious test of increasing
the memory available to the JVM by a factor of 8, but this did not help
(AFAICT my large game was running the garbage collector about once per
second, increasing the memory relaxed that to once every 3s).

Anyway, as I have a bit more time off ATM, I can give FreeCol a good
amount of attention, so I think we are ready to do an alpha-release.

Cheers,
Mike Pope


pgpjPqlYoGVi7.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

[Freecol-developers] desync hunt

[Michael T. Pope]

I am having no luck finding the desynchronization problem.  It is not
showing up in my overnight tests, but that just means it is triggered
by something that the AI does not do, which is a large search space.
I have not seen it in normal game play (although I have seen a bunch
of other bugs:-P).  So I have now arranged for the COMMS debug logs to
go to a fixed file, FreeColComms.log, in the same place as the current
FreeCol.log.  I am now testing what the impact of turning COMMS debug
mode on by default is --- if not too bad, I propose to do this for the
current trunk, albeit only until we either find or dismiss BR#3121.

Cheers,
Mike Pope


pgpcKud42BV34.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] 0.12.0, bug tracker update

[Michael T. Pope]

Here is the current bug update, with some progress.  I am hammering the
top bug hard ATM.  Reproducible test cases for the next three would be most
welcome.  Next most useful would be fix-confirmations.


Very serious, alpha-release blocking:
BR#3121 Cant attack shipt
Desynchronization.  Must fix, working on catching it now.

Serious, release blocking:
BR#3062 Map Explored Regions Error
The unexplored tiles fail, only blocking if we find a reproducable case
BR#3097 Resource count not updating autosave oddness
Main bug fixed, autosave directory weirdness remains
BR#3102 UI very slow - bug or feature^W normal?
Probably Java fail, hard to work on

Confirmation of fix needed:
BR#3083 Rapid Go-To Wont Wait
BR#3089 Trading with foreign powers under war for liberty fails.
BR#3095 Probably fixed by related BR#3098
BR#3108 "Stock market crash": price manipulation
BR#3111 Unable to trade with empty WagonTrain
BR#3117 Cant Unload in Europe
BR#3119 Not able to sail from europe if not active

Non-blocking:
BR#2926 map editor river bugs ver. 011.x
Minor UI issue
BR#2990 Log cluttered by i18n warnings
Minor log issue
BR#3025 Incorrect saves
Map editor fail, unclear
BR#3035 Minor UI issue
Broken key mapping for closing panels
BR#3051 Units wandering off, unclear
Units wandering off on their own
BR#3053 Problem(s) with meeting Europeans
Mostly fixed, left open to prompt dialog improvement
BR#3054 Unit heading in the wrong direction
Minor unit handling issue
BR#3060 Wagon Train displays Hammer Requirement Twice
Not reproducable
BR#3064 King wants twice
Not reproducable
BR#3065 Preferences Pane produces NPE
Not reproducable
BR#3077 Duplicate Session Exception for Monarch Session on Declaring Ind.
Not reproducable
BR#3079 Declaration of Independence appears and then disappears
Timeout?
BR#3081 Master Gunsmith Doesnt have connections
WWC1D?
BR#3090 Unable to start or load game - connection timed out
Not reproducable
BR#3103 no warning for task-less ship in Europe
Minor gameplay issue
BR#3106 UI bug: screen goes blank after cancelling map load
Trying to load a map as a game
BR#3118 Darkening terrain
wintertime is dealing with it


Cheers,
Mike Pope


pgpQU1AT3ndFq.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

[Freecol-developers] maps are not games

[Michael T. Pope]

We need to stop pretending that maps (the predefined ones, or those
created by the map editor) are games.  They are not, and this leads to
confusion such as in BR#3106.  Accordingly, I have added a user maps
directory under the user data directory (like the user saves and mods)
which is now the default location for the map editor to load and save
maps from/to.  User maps are also now shown in the map options dialog,
although this needs more work.

The next step is to rename all maps to a .fsm extension to further
differentiate them.

Cheers,
Mike Pope


pgpmhRquNjVPy.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Any blockers?

[Michael T. Pope]

On Sat, 18 Nov 2017 20:14:39 +
David Lewis  wrote:
> Do we have any remaining blockers?

Yes.  The UI slowness (BR#3102) is bad.  A hack that *might* fix it went in
only yesterday.  Feedback on that one is important.

A better question might be: `have you fixed all the bugs that came in
while you were busy?':-).  The answer to that one is no.  BR#3108 is an
easy cheat that has been broken before and I know how to fix, but just
have not got to yet.  BR#3111 is potentially serious, and the OP has just
responded with more detail, so I need to get to that too.   BR#3113 I do
not know what to do with.

Other than that, there are a whole heap of bugs in the open-need-info
state, often where I have put in a fix but lack confidence it has done the
full job.  I wish we had fewer of these, they do not inspire confidence.
There are also some like BR#3079 that are just hanging waiting for comment
(in that case, from you:-).

Cheers,
Mike Pope



pgpkQiJgQ03xZ.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Pull Request #7 Review...

[Michael T. Pope]

On Tue, 07 Nov 2017 16:55:05 +
David Lewis  wrote:
> Please review Pull Request #7:
> https://github.com/FreeCol/freecol/pull/7

The title suggests this a fix for the entryLocation stuffup, which is
now fixed (properly, it was only happening because I broke the
serialization of Player).  However a really quick look shows there are a
bunch of unrelated cleanups in there as well.  Can I leave it to you to
merge in what you think is useful?  Despite a productive weekend, we
still have new open bugs that I should look at first.

Cheers,
Mike Pope
  


pgp86t4vumSok.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] 0.12.0, bug tracker update

[Michael T. Pope]

On Wed, 27 Sep 2017 19:05:16 +0930
"Michael T. Pope" <mp...@computer.org> wrote:
> On Tue, 26 Sep 2017 22:20:55 +
> David Lewis <highwayofl...@gmail.com> wrote:
> > I finally managed to reproduce the server connection issue.

Added a better fallback for host resolution in git.b578952.  Please test.

OTOH bad news on stability/release-worthiness.  I am having trouble
starting new games.  There is more weirdness with UpdateMessage still.

Cheers,
Mike Pope


pgpYcRy6OiZXj.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] 0.12.0, bug tracker update

[Michael T. Pope]

On Tue, 26 Sep 2017 22:20:55 +
David Lewis  wrote:
> I finally managed to reproduce the server connection issue. I was going to
> update the ticket, but SourceForge is down currently.
> This weekend while I was out of town, I booted up my computer with no Wifi
> connection and encountered the issue. Interestingly, the I could fix it by
> changing the server address from 0.0.0.0 to 127.0.0.1, but maybe that gives
> a hint to reproduce.

That strongly suggests that the problem occurs when the server host
address is not resolvable, possibly due to no DNS, as would be the case on
a laptop with no network.  I saw the issue just today when I tried to run
freecol on a machine that was incorrectly named, as once again the host
address could not be found.  We need to do better than this, so I will
look for a workaround.

Cheers,
Mike Pope


pgp91Gf7zCl9L.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] 0.12.0, bug tracker update

[Michael T. Pope]

On Fri, 22 Sep 2017 07:54:42 +0930
"Michael T. Pope" <mp...@computer.org> wrote:
> Ordinary single unit animation should be more reliable now, but the full
> complexity of the problem is not completely fixed yet (try a complex game
> and hit the "execute orders" command to see the carnage), but the main
> thing blocking it is.  Hoping to sort that out this weekend.

Amazing, the previous fixes did most of the job, and the BR#3089 issue
turned out to be simple.  I will be back to play testing soon, but it
seems BR#3013 is still alive.  However, David, I am now unaware of
anything that should block an alpha-release.

Cheers,
Mike Pope


pgpLYx1XT_fQs.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] 0.12.0, bug tracker update

[Michael T. Pope]

> The other problem is that move animation is racing.

A big piece of leftover work from the DOM-removal is needed to fix this.
Pity, I was hoping to be able to leave it out.  I just committed the main
parts (git.7a6f8f7, git.549b504).  My overnight tests are looking good
with these changes, but there is a fair bit of new code so I fear I have
just destabilized the tree again.

Ordinary single unit animation should be more reliable now, but the full
complexity of the problem is not completely fixed yet (try a complex game
and hit the "execute orders" command to see the carnage), but the main
thing blocking it is.  Hoping to sort that out this weekend.

Cheers,
Mike Pope


pgpGMYhQePH5a.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] 0.12.0, bug tracker update

[Michael T. Pope]

On Sat, 12 Aug 2017 10:20:47 +0930
"Michael T. Pope" <mp...@computer.org> wrote:
> Updating the blocker status since last round:

Updating again.  IMHO there are two hard blockers ATM/ 

> BR#3083  Y  Rapid Go-To Wont Wait

This is still broken in a test game I have.  Working on it.

The other problem is that move animation is racing.  Quite often the unit
is shown in its destination tile, and then moved there.  The combat
animations are sometimes out of order as well but I am having a harder
time triggering this.  I can see what is wrong, but the fix is proving
elusive.

We also have two bugs that would be blockers if they were more common and
reproducible:

- I am still worried about BR#3090 as that totally blocks the game
  from working

- If we get more signal for BR#3062 that should be top priority to fix

Cheers,
Mike Pope


pgpxUy_nNsK0I.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] test fail

[Michael T. Pope]

On Fri, 08 Sep 2017 17:44:48 +
David Lewis  wrote:
> Yes, I agree, so what I did was change it to a 100th...
> 
> + final int alarmBonus = -Math.round(price * 0.001f * getGame().
> getSpecification()
> + .getInteger(GameOptions.ALARM_BONUS_SELL));
> Meaning that if the price of goods is 1064 * .001 * 40 (%) = (round) 43

Argh.  The numbers/result/intent make sense, but the code had me
completely mislead.  Please, if we are using a *percentage* option
can we have it work as a percentage option, not a 
percentage-with-hidden-further-division-by-10-option?  We are trying to
get rid of hidden magic numbers and you just snuck a magic 10 back in!
Also remember, this is what we are telling the users:

model.option.alarmBonusSell.shortDescription=Percent bonus on native alarm when 
selling goods to a native settlement.

which is a bit unfair when it is really:
 ...=Percent bonus on native alarm when selling goods to a native settlement 
which is then divided by 10.

As things stand in the code, anyone looking at csBuy/Sell/Gift will see
0.001f in two out of three places and be naturally lead to suspect that
there is a bug.  Merging the hidden extra divisor into the expected 0.01f
conversion factor obscures what is going on.  Really strict coding
standards (which we do *not* have here:-) would insist on not even having
a bare 0.01f, but for that too to be an explicit named constant (e.g.
"final float PERCENT_TO_FLOAT_CONVERSION = 0.01f;").  We do not need to go
that far, but the current code definitely needs improvement.

> Old value was: 1064/50 = 21.
> Probably means we should change the sell default value to 20%, rather than
> 40%.
> So: 1064 * .001 * 20 = 21, which would match the current alarm change for
> selling goods.

If you want to preserve the existing value, why not just dump the
extra divisor but use a value of 2%?  However I thought we had agreed that
the existing value is too low, hence my suggestion of 10%.  If that seems
too high we can just double the existing situation with 4%.

> Gifting I think should be double, so if it's default were 40%, and you gave
> those 100 trade goods to the natives, it's alarm change value would be -43,
> which I think seems reasonable?

I think gifts should be worth sales * n ; n in { 1.5 .. 2 }.  If we get
sales right gifts follow.
 
> Only the buy value is: *.01 * (%), so a purchase of 100 would be:
> 91 * .01 * 80 (%) = -73 alarm change. But maybe it should be 20% as well by
> default.
> 91 * .01 * 20 (%) = -18 alarm change.
> Currently, a purchase is:
> 91 / 50 = -2 alarm change.

I am less worried by purchasing as the values are lower in general and are
less likely to be abusable to easily pacify a neighbouring tribe.  IMHO
purchasing *should* be less effective as all you are doing for the tribe
is removing surplus goods, whereas sales/gifts you are providing them with
something they want that they do not have.  There is a qualitative
difference.  So I believe buy% == sell% is fine as a starting point.

Cheers,
Mike Pope


pgpMk7oD_WQhn.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] test fail

[Michael T. Pope]

On Thu, 07 Sep 2017 14:50:32 +
David Lewis  wrote:
> Can you review the open pull requests and if they look good let me know so
> I can merge them?

I am a bit backlogged ATM, but did have a quick look the other day. There
were several issues with the gifts one, but the real showstopper there is
that we need to work out reasonable values for the magic numbers.  I
agree ATM the price/50 value is too low, but I suspect price * 40% goes
the other way.

It is not too hard to to sell a high value cargo for 1000 gold (I just
tried with a starting game and 100 Trade Goods and got an initial offer of
1064 from the Arawak), so that is a change of around -400 alarm.  The
*entire* meaningful range of alarm is from HAPPY(100) to HATEFUL(1000)
(see Tension.Level), so all it would require is 2 big trades to go from 
near war (ANGRY(800)) down to happy again.  That seems too fast to me.
My suggestion is values of 10%/10%/15%, but admit I (semi-)pulled these
numbers out of the air (100 is the minimum alarm distance between named
levels), and thus would really like some rationale, or even better,
actual Col1 measurements to base this on.

The deSoto one is fine and does the job.  Thanks for following this up.
However looking at it reminded me just what a mess LCR.chooseType is:-P.
Feel free to commit, but I am seriously tempted to rewrite the whole
routine for clarity.

Should have some time over the weekend to catch up.  Playtesting has
thrown up a few weird things I need to follow through on, notably I am
unhappy with the fix for BR#3083.

Cheers,
Mike Pope


pgpH5idzaACm_.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] test fail

[Michael T. Pope]

On Thu, 31 Aug 2017 23:24:03 +
David Lewis  wrote:
> Current ant task dist is failing because of:
> 
> installer-translations:
> 
>  [java] Could not find net.sf.freecol.tools.InstallerTranslations. Make
> sure you have it in your classpath

Should be fixed.
 
> freecol-git/build.xml:352: com.izforge.izpack.compiler.CompilerException:
> null:52: Resource not found: /Users/davlewis/
> github.com/freecol-git/build/installer/lang.xml_cat

Not seeing this.  lang.xml_cat is in build/installer.  Some sort of path
problem?

Cheers,
Mike Pope


pgpdXrQ5Ibm9t.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] test fail

[Michael T. Pope]

On Thu, 31 Aug 2017 17:30:15 +
David Lewis  wrote:
> Yeah, the tests need a lot of love. I enabled the simpleMove test purely
> for the sake of using the client helper tests. Although those should be
> their own tests, I am still learning the system, so haven't created a
> client test yet.

I am unconvinced that is going to provide much benefit.  The client code
is likely to be race-prone, and thus difficult to make stable tests for.
The fact that we have only one (previously disabled) client test was
likely for good reason.  OTOH there are many critical routines that would
benefit from small scale unit tests that require neither client or server
processes... lots of low hanging fruit that would really improve the test
suite coverage.

> At the moment I'm cleaning up and fixing the build.xml file (creating a new
> one for the time being) that will be designed to create packages from
> Travis and be deployed automatically so we don't have to do any of that
> manually.

I am wary of adding travis as a build dependency.  I am sure it is very
nice, but adding another step in the learning curve needs some
justification.  Automatic package addition is not particularly
convincing.  Adding packages is *very* rare. I think I have done it once. 

> There are a number of dependency issues that need to be solved
> before distributions can be made. I've figured out most of the errors, and
> now just a matter of cleaning things up. There are a lot of legacy settings
> in there.

Not sure what you have hit here.  Can you give an example?

> Travis is currently only failing on 2 tests, it can't find the sound mixer.
> Likely because it's a container.

Looks like it to me.  The SoundPlayer code is not very resilient.  Feel
free to rework either it or the tests.  I would be inclined to just disable
sound tests if AudioSystem.getMixerInfo returns no signs of a mixer being
present.

Cheers,
Mike Pope




pgpfOwcRAikgX.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] test fail

[Michael T. Pope]

On Thu, 31 Aug 2017 00:24:31 +
David Lewis  wrote:
> That's odd... it succeeds on my local machine and local build machines
> (docker containers), and succeeds on the Travis CI build servers (each run
> `ant test`)...
> 
> There are 2 tests that fail on the remote build nodes: mixer isn't
> available on build nodes. But I don't see any NPE's.
> I enabled the simpleMove test, which was disabled, and modified the client
> connect helper significantly because it was broken.

OK, AFAICT the client connect helper is *only* used for testSimpleMove,
which is suggestive.  I do not recall why simple move testing was
disabled, but I suspect there is some lurking breakage.  The test itself
is a bit lame --- if we were really just testing the simple-move routines
we could do a lot better job and without starting a client.  So if we can
not sort this out soonish I recommend just disabling it again.

The fact that I am only seeing it on one machine (a new one) which
otherwise has the same software setup as my usual development box suggests
some sort of timing effect.

> Can you try doing a clean checkout (or clone new repo) and try again?

OK, when I get back to the machine that shows the failure.

> Which version of of the JDK are you using?

Java vendor: Oracle Corporation
Java version: 1.8.0_141
Java WM name: OpenJDK 64-Bit Server VM
Java WM vendor: Oracle Corporation
Java WM version: 25.141-b16

Its always whatever the latest release on Fedora is, and thus is
usually quite up to date.

Looking again at the crash, it seems very entwined with the Locale
setting, which is weird.  I have tightened up the Locale handling
(git.751b33d), perhaps that will help.

Cheers,
Mike Pope


pgpfENIAziDTS.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] test fail

[Michael T. Pope]

On Wed, 30 Aug 2017 19:10:08 +0930
"Michael T. Pope" <mp...@computer.org> wrote:
> I just did some play testing...

To clarify, I wrote this to David, but mucked up the send.

Cheers,
Mike Pope


pgpvASQ1lteBM.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Release 0.12.0 Status

[Michael T. Pope]

On Mon, 21 Aug 2017 22:41:25 +
David Lewis  wrote:
> There is a release blocker (BR3090)...

David (in particular) and others in general --- I am having trouble
replicating BR#3090.  I just improved the logging so as to get more clues
(git.5f533bb).  Can someone break it for me and attach the connection
logging?  The dodgy commit is: 015a7355.

Cheers,
Mike Pope


pgpWW6iGRziyW.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] Release 0.12.0 Status

[Michael T. Pope]

On Mon, 21 Aug 2017 22:41:25 +
David Lewis  wrote:
> There is a release blocker (BR3090), and a high priority issue (3089) on
> the list at the moment.

BR#3089 is blocker-worthy as well.  AFAICT if the REF wins, the game then
goes on forever without informing you.  I am working on it, but my test
games keep throwing up distracting problems.

Cheers,
Mike Pope


pgpj1NSiQmlqN.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] 0.12.0, bug tracker update

[Michael T. Pope]

Updating the blocker status since last round:

On Sat, 29 Jul 2017 13:04:47 +0930
"Michael T. Pope" <mp...@computer.org> wrote:
>...
> BR#3058  Y  Custom difficulty fun, working on this now
> BR#3060  N  Wagon train requirement, waiting for reproducible case
> BR#3061  ?  Requirements panel crash, unclear
> BR#3062  Y  Map exploration failing, this is bad, hoping for reproducible case
> BR#3064  N  Double monarch demand, can not reproduce
> BR#3065  N  Preferences pane, waiting for reproducible case
> BR#3066  Y  Number of immigrants failed, working on this next
> BR#3068  N  More unit-type-change in mods, unclear

BR#3058 and BR#3066 are fixed.  BR#3061 is minor and not reproducible so
its non-blocking.

BR#3062 remains at large and is a serious problem.  It is almost certainly
a broken update from the server to the client, which means it is not easy
to reproduce.  We will need a COMMS mode debug trace to make progress
here.  I would really like to nail this one before release, but its going
to be tough.

> I also have a blocker due to some of my old (0.11.*) games crashing
> on load.  Should have this done soon.

This is done as mentioned earlier.

Moving onto the newer open reports:

BR#3077  N  Duplicate Session Exception for Monarch Session on Declaring Ind.

I can not reproduce this.

BR#3079  N  Declaration of Independence appears and then disappears 

Timing issue.

BR#3081  N  Master Gunsmith Doesnt have connections

WWC1D issue, should be moved to the Pending Features list.

BR#3083  Y  Rapid Go-To Wont Wait

Serious problem, makes late game play where you have lots of go-to orders
borderline unplayable.  I have started working on this, but it requires
some major surgery to the client controller, and so the fix will need
play testing

Cheers,
Mike Pope


pgp0Gams3at2t.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] 0.12.0

[Michael T. Pope]

On Thu, 10 Aug 2017 17:57:26 +
David Lewis  wrote:
> I agree that 3083 should be fixed before release, that is currently the
> biggest annoyance in the game.

Its now top of the list.  However, once fixed, its going to need
play testing as there are a lot of cases.
 
> Part of the reason I'd like to get this release out sooner rather than
> later (RERO: Release Early, Release Often)...

All true.  However we have had a few "Oh shit" releases, where we put
out version N only to have to put out N+1 almost immediately to fix a
glaring bug.  Perhaps I should pay less attention to this as it would now
be the new release manager's problem:-).  You could equally argue that
because it is a while since the last release a bit more testing will not
matter that much.  I certainly would prefer the bug flux settles down from
current levels.  It has been a busy week on the bug tracker.

> My background in working for Starbucks Technology, Disney Interactive, and
> Marvel Games is that early and frequent releases created a tighter feedback
> loop between developers and testers or users, and generally garnished
> higher usage. I believe it would allow the game development to progress
> faster, and since it puts the newer code in the hands of the users,
> enabling them to help define what the game will become, and ultimately
> result in higher quality software.

Agreed in general.  Pity this release required a major rewrite that took
way longer than it should have.

> ...just stating why I'm hoping we can do a release soon.

Understood and generally agreed.  The question then is "how soon do you
want to do 0.12.1?":-).

Cheers,
Mike Pope


pgp7rywoWs7ml.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] 0.12.0

[Michael T. Pope]

On Thu, 10 Aug 2017 01:43:56 +
David Lewis  wrote:
> There's a new bug report where the version attribute isn't set in the
> savegame file and thus doesn't load the unit-change-types correctly,
> causing an NPE on selecting a teacher. That's the only one I've found thus
> far.

Will check.  I am surprised though, surely we have had the version in
there since 0.10.x.

> I'd like to set a goal of releasing by Tuesday, August 22nd if there are no
> major blocking issues and if there are no objections. I've read through the
> release checklist and am prepared to do the release.

That sounds a bit aggressive.  I looked at BR#3083 at lunch today.  I think
we should sort that out, because it can be really annoying.  I am also
still hoping you can find a test case for BR#3062.
 
> What's the process for ensuring all translation strings are up to date?
> There were a few new strings added that haven't been updated in the
> language packs yet.

There is always lag in translations.  They do great work, but once again,
its all dependent on volunteers finding time.  Usually we try to have a
couple of weeks with no string changes for stability purposes.

Cheers,
Mike Pope


pgp6ydQuxfOlP.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Re: [Freecol-developers] 0.12.0

[Michael T. Pope]

On Sat, 29 Jul 2017 13:04:47 +0930
"Michael T. Pope" <mp...@computer.org> wrote:
> I also have a blocker due to some of my old (0.11.*) games crashing
> on load.  Should have this done soon.

This is now resolved.  I can not find any 0.11.x games of mine or attached
to current bugs that has any loading problems.  Now would be a really good
time to let us know if anyone has a counter example!

Cheers,
Mike Pope


pgpYkwSWyH6n6.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers