I don't think I have ever seen Awarak cities before.
Regards
Michael
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers
On 01/06/2015 05:07 AM, Michael T. Pope wrote:
> On Thu, 01 Jan 2015 17:29:46 +0100
> Michael Vehrs wrote:
>> It seems the natives are able to reclaim tiles lost to a European colony
>> when the colony changes hands.
> Should be there in git.30c8cf4. Had a small speed b
It seems the natives are able to reclaim tiles lost to a European colony
when the colony changes hands. In the screenshot attached, the lower
right tile has been plowed, which implies it must have belonged to the
English at one point, but now that the French have taken the colony, the
tile belo
On 12/06/2014 10:12 AM, Michael T. Pope wrote:
On Sat, 06 Dec 2014 09:39:52 +0100
Michael Vehrs wrote:
It is an English dragoon demanding of a French colony. Notice the small
splash of blue under the horse's hooves. The other red color chip
belongs to the English ship.
OK. Added to the
On 12/03/2014 09:57 PM, Michael T. Pope wrote:
> On Wed, 03 Dec 2014 17:24:42 +0100
> Michael Vehrs wrote:
>
>> DOS version 3.0 Difficulty Viceroy
>> [English demanding silver]
> Good to have that confirmed, but I am confused by the 8-bit graphics:-).
> I am guessi
DOS version 3.0 Difficulty Viceroy
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exp
On 10/20/2014 11:53 AM, LoneVVolf wrote:
> Hi,
>
> a comment by Kamos (
> http://sourceforge.net/p/freecol/wiki/WWC1D%20-%20resource%20output%20v2/#cd6a
> ) made me check major rivers in Col1 .
>
> This is what i've found :
>
> Col1 has minor & major rivers
> Both are terrain features , NOT terrain
case. This whole construct
is a conditional format that works as follows: "plural" is a "tag", i.e.
a fixed string that determines how the next element, the "selector" is
to be interpreted. "%turns%" is the selector. It is expected that this
variable will
On 04/27/2014 02:38 PM, Michael T. Pope wrote:
> Beware that the REF is broken in trunk, and will be flakey for a bit while
> I fix a few things and add a bit of behavioural variability.
>
> The most recent flaw was somewhat encouraging--- the REF was having
> trouble finding the colony to attack,
On 04/16/2014 02:11 PM, Michael T. Pope wrote:
> On Wed, 16 Apr 2014 07:23:03 +0200
> Michael Vehrs wrote:
>> Was that ever fixed? I can't recall that happening.
> You are right, it still happens in current games. Its probably just more
> obvious in the new tiles.
>
&g
On 04/15/2014 12:34 PM, Michael T. Pope wrote:
> On Sun, 06 Apr 2014 15:38:48 +0200
> Michael Vehrs wrote:
>> The rivers have been moved off-center. Rivers and forests have been
>> auto-generated. If you consider the approach worthwhile, I will improve
>> the rivers.
>
On 04/16/2014 04:21 AM, Michael T. Pope wrote:
> On Tue, 15 Apr 2014 19:21:37 +0200
> Petr FiĊĦer wrote:
>> Glad to help.
>> And don't worry about the credit, I don't care about it. :)
> No worries. I'd fix it but git is resistant to changing commit messages...
>
> This is probably a good point to
On 04/09/2014 12:17 AM, Michael T. Pope wrote:
> On Sun, 06 Apr 2014 15:38:48 +0200
> Michael Vehrs wrote:
>> In order to try this for yourself, you need to generate tiles with the
>> ForestMaker and RiverMaker tools, and change resources.properties to use
>> the new til
I managed to snatch failure from the jaws of success, but I'm still
working on this. A preview looked quite good, but then I realized, that
the rivers must be moved to the NW and NE edges of the tile in order to
avoid occlusion. I hope I will be able to provide a few screen shots
during the nex
On 03/09/2014 05:28 AM, Michael T. Pope wrote:
> On Wed, 05 Mar 2014 07:04:50 +0100
> Michael Vehrs wrote:
>> All right, then. Let the players use everything implemented and complain
>> about what is still lacking. What, no Southern Cross? What, no _Southern
>>
On 03/09/2014 05:28 AM, Michael T. Pope wrote:
> On Wed, 05 Mar 2014 07:04:50 +0100
> Michael Vehrs wrote:
>> All right, then. Let the players use everything implemented and complain
>> about what is still lacking. What, no Southern Cross? What, no _Southern
>>
On 03/04/2014 09:58 AM, Michael T. Pope wrote:
> On Tue, 04 Mar 2014 08:18:06 +0100
> Michael Vehrs wrote:
>> The flag generator seems to be in a usable state now. Javadoc needs to
>> be added, and it might be a good idea to prevent some of the more ugly
>> combina
The flag generator seems to be in a usable state now. Javadoc needs to
be added, and it might be a good idea to prevent some of the more ugly
combinations of backgrounds and decorations. On the other hand, if the
player wants to make his eyes water, why should we care? So unless there
are any o
On 01/29/2014 10:17 PM, LoneVVolf wrote:
> Hi,
>
> With latest trunk revision building fails :
[snip, snip]
>
> BUILD FAILED
> ``
>
> Lone_Wolf
>
Sorry about that. My git-fu is somewhat lacking. I have committed the
missing changes now.
Regards
Michael
---
On 01/13/2014 11:57 AM, Michael T. Pope wrote:
> On Sun, 12 Jan 2014 13:21:24 +0100
> Michael Vehrs wrote:
>> java -cp FreeCol.jar
>> net.sf.freecol.tools.FlagTest
> Cool. I would say go ahead and integrate it into the declaration dialog
> if you have time. A release i
On 01/11/2014 04:08 PM, Michael Vehrs wrote:
> On 12/27/2013 04:40 AM, Bryce W. Harrington wrote:
>> On Fri, Dec 27, 2013 at 12:18:09PM +1030, Michael T. Pope wrote:
>>> On Wed, 25 Dec 2013 14:39:34 +0100
>>> Michael Vehrs wrote:
>>>> Well, it might be best
On 01/12/2014 11:20 AM, Michael T. Pope wrote:
> BR#2643 is a new interesting fail following the role changes. The
> game contains a REF unit that is an armed FreeColonist. The REF has
> captured a large city, and it looks like the AI is now smart enough to
> arm loose units and use them against
On 12/27/2013 04:40 AM, Bryce W. Harrington wrote:
> On Fri, Dec 27, 2013 at 12:18:09PM +1030, Michael T. Pope wrote:
>> On Wed, 25 Dec 2013 14:39:34 +0100
>> Michael Vehrs wrote:
>>> Well, it might be best to let the REF keep the colour, and to force the
>>> pl
On 01/07/2014 01:59 AM, Michael T. Pope wrote:
> On Tue, 07 Jan 2014 01:16:31 +0100
> LoneVVolf wrote:
>> ...do you want me to open a feature request ?
> Only if you can show that Col1 generated maps included hills with rivers.
> If not, I am inclined to just regard it as a quirk of their map edit
On 01/05/2014 01:54 AM, Michael T. Pope wrote:
> On Sat, 4 Jan 2014 17:33:20 +0100
> "Lone_Wolf" wrote:
>> To compare Col1 and freecol resource output i need to know what the
>> difficulty setting other > tile production does.
> "Other" contains the default values shown when you choose the "Custom
On 12/24/2013 01:00 AM, Michael T. Pope wrote:
> On Mon, 23 Dec 2013 13:15:10 +0100
> Michael Vehrs wrote:
>> It seems that the forest maker tool was not broken after all. I have
>> committed sample forest tiles with river cut-outs. Not much of an
>> improvement in g
On 12/17/2013 11:08 AM, Michael T. Pope wrote:
> In git.1a5417c the old version of FreeColDialog has finally gone away,
> and with it the getResponse family of bugs. Or at least I can not
> reproduce it any more. As previously admitted, there are
> look-and-feel issues outstanding, and doubtless
On 12/01/2013 01:26 AM, Michael T. Pope wrote:
> What is the Right Thing to do about:
>BR#2594 Keyboard Accelerator configuration can break stock keyboard
> shortcuts
> AFAICT the report is correct, but there is a limit to how much we can
> do to prevent users messing up their configuration.
On 10/05/2013 10:12 AM, Michael T. Pope wrote:
> On Sat, 05 Oct 2013 08:19:20 +0200
> Michael Vehrs wrote:
>> Unfortunately, swing does not follow the platform's UI conventions with
>> regard to button placement, which means that the new dialogs place their
>> button
On 10/05/2013 05:59 AM, Michael T. Pope wrote:
> On Fri, 04 Oct 2013 15:56:28 +0200
> Michael Vehrs wrote:
>> I understand now. Try the attached patch for size.
> Ta. That broke the blockage I was experiencing. I kicked it a bit more,
> and now with git.561ef0c we have too
On 10/04/2013 12:10 PM, Michael T. Pope wrote:
On Fri, 04 Oct 2013 11:50:53 +0200
Michael Vehrs wrote:
At the moment, I am experiencing the following option-related glitch: If
I view the immigration section of the difficulty settings, the unit type
of the immigrant is displayed only once. On
On 10/03/2013 01:28 PM, Michael T. Pope wrote:
> I am struggling to get all the options displaying correctly and/or
> consistently. AFAICT as of the last patch they are working (across
> preferences, difficulty, map options and game options), but without
> descriptions of the String/SelectOption[1
On 10/03/2013 01:28 PM, Michael T. Pope wrote:
> I am struggling to get all the options displaying correctly and/or
> consistently. AFAICT as of the last patch they are working (across
> preferences, difficulty, map options and game options), but without
> descriptions of the String/SelectOption[1
On 09/22/2013 01:20 PM, Michael T. Pope wrote:
> On Sat, 21 Sep 2013 11:59:08 +0200
> Michael Vehrs wrote:
>> I have widened the EndTurnDialog. It turned out to be easy and
>> straightforward. However, it took me quite a while to figure out that my
>> code was, in fact, wo
On 09/22/2013 10:38 AM, Michael Vehrs wrote:
> On 09/18/2013 10:12 AM, Michael T. Pope wrote:
>> In git.eb4564c have got rid of another FreeColDialog, the one that
>> displays a group of ModelMessages. The replacement uses the
>> (surprisingly rarely used) InformationPanel,
On 09/18/2013 10:12 AM, Michael T. Pope wrote:
> In git.eb4564c have got rid of another FreeColDialog, the one that
> displays a group of ModelMessages. The replacement uses the
> (surprisingly rarely used) InformationPanel, to which I have added
> optional buttons to display the source of the mes
On 09/18/2013 10:12 AM, Michael T. Pope wrote:
> In git.eb4564c have got rid of another FreeColDialog, the one that
> displays a group of ModelMessages. The replacement uses the
> (surprisingly rarely used) InformationPanel, to which I have added
> optional buttons to display the source of the mes
On 09/19/2013 02:33 PM, Michael T. Pope wrote:
> On Mon, 09 Sep 2013 12:14:32 +0200
> Michael Vehrs wrote:
>> This isn't pretty, but it does work:
>>
>> public boolean showConfirmDialog(String text, String okText, String
>> cancelText) {
>>
On 09/18/2013 10:12 AM, Michael T. Pope wrote:
> In git.eb4564c have got rid of another FreeColDialog, the one that
> displays a group of ModelMessages. The replacement uses the
> (surprisingly rarely used) InformationPanel, to which I have added
> optional buttons to display the source of the mes
On 09/15/2013 01:14 PM, Michael T. Pope wrote:
> On Fri, 13 Sep 2013 21:57:53 +0930
> "Michael T. Pope" wrote:
>> The next obvious category are dialogs that do not really need to be modal.
>> Many of the uses of showConfirmDialog are asking pretty critical
>> questions (e.g. reconnect, quit, etc).
On 09/13/2013 04:04 PM, Michael Vehrs wrote:
> On 09/13/2013 02:40 PM, Michael T. Pope wrote:
>> On Fri, 13 Sep 2013 11:22:43 +0200
>> Michael Vehrs wrote:
>>> I have eliminated the test failure by accounting for the corner corner
>>> case of hardy pioneers wit
On 09/13/2013 02:40 PM, Michael T. Pope wrote:
> On Fri, 13 Sep 2013 11:22:43 +0200
> Michael Vehrs wrote:
>> I have eliminated the test failure by accounting for the corner corner
>> case of hardy pioneers with tools. Unit.getLabel() does not include the
>> tool count, w
On 09/12/2013 02:33 PM, Michael T. Pope wrote:
> Ouch, hope those test errors get fixed. Speaking of which, what is
> the state of the roles cutover? The test failure is due to "Hardy
> Pioneer" not matching "Hardy Pioneer pioneer" as currently returned by
> Messages.message(unit.getLabel()). Is
On 09/12/2013 02:33 PM, Michael T. Pope wrote:
> Ouch, hope those test errors get fixed. Speaking of which, what is
> the state of the roles cutover? The test failure is due to "Hardy
> Pioneer" not matching "Hardy Pioneer pioneer" as currently returned by
> Messages.message(unit.getLabel()). Is
On 09/09/2013 02:00 AM, Michael T. Pope wrote:
> On Sat, 31 Aug 2013 20:51:50 +0930
> "Michael T. Pope" wrote:
>> This suggests that the least disruptive path is to make FreeColPanel
>> extend JDialog, with controllable modality defaulting to non-modal.
> I had a bit of a try at this over the week
Checking the naval advisor panel, I noticed the tool tip "1
Merchantmen", which should have been "one Merchantman" according to my
understanding of the code. So I added a test to the TestMessages suite.
And the test succeeds. How is that possible?
Regards
Michael
---
On 08/27/2013 02:12 PM, Michael T. Pope wrote:
> On Tue, 27 Aug 2013 13:45:04 +0200
> Michael Vehrs wrote:
>> As it turns out, it was a bit trickier than I thought. Still, I have
>> committed a first implementation of the new unit label. It causes
>> another label-relat
On 25.08.2013 11:29, Michael T. Pope wrote:
> On Sun, 25 Aug 2013 10:24:16 +0200
> Michael Vehrs wrote:
>
>> I have gathered a list of unit labels, as used by FreeCol and the
>> original game, as far as I can determine. The entry for Free Colonist is
>> representat
On 25.08.2013 11:29, Michael T. Pope wrote:
> On Sun, 25 Aug 2013 10:24:16 +0200
> Michael Vehrs wrote:
>
>> I have gathered a list of unit labels, as used by FreeCol and the
>> original game, as far as I can determine. The entry for Free Colonist is
>> representat
I have gathered a list of unit labels, as used by FreeCol and the
original game, as far as I can determine. The entry for Free Colonist is
representative for all unit types that represent people with no expert
role, the entry for Caravel is representative for all unit types that do
not represen
On 18.08.2013 03:37, Michael T. Pope wrote:
> On Sat, 17 Aug 2013 14:42:28 +0200
> Michael Vehrs wrote:
>
>> It probably doesn't matter, as long as we ensure that setRole() or its
>> successor is called during initialisation.
>>
> AFAICT role is
On 13.08.2013 12:02, Michael T. Pope wrote:
> How should we handle backward compatibility for the roles?
> Specifications in saved games from<= 0.10.5 will not have a
> section.>= 0.10.6 have a roles section with two bugs: omitted
> model.role.default and model.role.scout does not include the
> cap
On 15.08.2013 10:40, Michael T. Pope wrote:
> On Sun, 11 Aug 2013 15:54:29 +0200
> Michael Vehrs wrote:
>
>> Update: I have fixed all test failures except for six that occur only
>> when running all tests, but not when running the test suite
>> individually. I co
On 11.08.2013 12:59, Michael T. Pope wrote:
> On Sun, 11 Aug 2013 12:30:20 +0200
> Michael Vehrs wrote:
>
>> Update: I have fixed all test failures except for six that occur only
>> when running all tests, but not when running the test suite
>> individually. I co
On 11.08.2013 09:13, Michael Vehrs wrote:
> On 10.08.2013 12:32, Michael T. Pope wrote:
>
>> On Sat, 10 Aug 2013 11:39:40 +0200
>> Michael Vehrs wrote:
>>
>>
>>> Excellent. The change role message is, of course, an essential part of
>>>
On 10.08.2013 12:32, Michael T. Pope wrote:
> On Sat, 10 Aug 2013 11:39:40 +0200
> Michael Vehrs wrote:
>
>> Excellent. The change role message is, of course, an essential part of
>> switching to a role model.
>>
> No worries. What is your preferred sequ
On 10.08.2013 11:23, Michael T. Pope wrote:
> On Sat, 10 Aug 2013 09:35:32 +0200
> Michael Vehrs wrote:
>
>> Recently, I attempted replacing the current equipment-based model with a
>> role-based model. The required changes are pervasive and are certain to
>> i
Recently, I attempted replacing the current equipment-based model with a
role-based model. The required changes are pervasive and are certain to
introduce any number of bugs. Therefore, I propose a gradual migration.
As a first step, the Role enum could be replaced with a Role class. This
is no
On 20.07.2013 13:27, Michael T. Pope wrote:
> On Sat, 20 Jul 2013 12:42:00 PM Michael Vehrs wrote:
>
>> I have created the ForestMaker tool to generate forest tiles, including
>> forest tiles with river cut-outs, from a list of suitable tree images. I
>> think the resu
On 29.06.2013 06:00, Michael T. Pope wrote:
> Yet another heads up wrt trunk. I am working on the disappearing
> settlements bug (the one where a settlement disappears or changes
> while you can not see it, currently this correctly does not update
> during the game, but will incorrectly if you sav
On 30.04.2013 13:30, Michael T. Pope wrote:
> On Sat, 27 Apr 2013 08:10:44 PM Michael T. Pope wrote:
>
>> On Sat, 27 Apr 2013 10:07:34 AM Michael Vehrs wrote:
>>
>>> As it turns out, all test failures can be fixed with the attached
>>> one-liner. Wha
On 28.04.2013 09:48, Kyle Richesin wrote:
> Hello everyone,
>
> I've recently been playing around with the FreeCol code and for the
> most part I've not had alot of trouble.
> However I tried to modify something in
> data/rules/classic/specification.xml, and nothing appears to have
> happened. I
On 27.04.2013 12:40, Michael T. Pope wrote:
> On Sat, 27 Apr 2013 10:07:34 AM Michael Vehrs wrote:
>
>> As it turns out, all test failures can be fixed with the attached
>> one-liner. What next?
>>
> I need to see if (add one-liner, revert df63b36) still breaks
On 21.04.2013 13:21, Michael T. Pope wrote:
On Sun, 21 Apr 2013 09:54:45 AM Michael Vehrs wrote:
After some minor difficulties with git, I have reverted my development
branch to
b56c15c.
I usually do:
git checkout -b
git reset --hard
to get to a particular commit.
Hopefully
On 20.04.2013 17:16, Michael T. Pope wrote:
> On Sat, 20 Apr 2013 02:33:43 PM Michael Vehrs wrote:
>
>> I don't see why the AI needs to know anything about production types
>> before the game has been fully initialized.
>>
> I doubt it does. I think the A
On 20.04.2013 14:20, Michael Vehrs wrote:
> On 17.04.2013 12:21, Michael T. Pope wrote:
>
>> On Sun, 14 Apr 2013 04:15:09 PM Michael Vehrs wrote:
>>
>>
>>> I have committed a preliminary solution. There will be room for
>>> improvement, I e
On 17.04.2013 12:21, Michael T. Pope wrote:
> On Sun, 14 Apr 2013 04:15:09 PM Michael Vehrs wrote:
>
>> I have committed a preliminary solution. There will be room for
>> improvement, I expect.
>>
> Alas so. The AI performance regressed so something is/was sti
On 14.04.2013 13:20, Michael T. Pope wrote:
> On Sun, 14 Apr 2013 09:36:53 AM Michael Vehrs wrote:
>
>> Confirmed. I get this message
>>
>> net.sf.freecol.common.networking.ServerAPI askExpecting
>> WARNING: Received error response: server.userNameNotP
On 14.04.2013 13:23, Michael T. Pope wrote:
> On Sun, 14 Apr 2013 09:53:42 AM Michael Vehrs wrote:
>
>> No, that would not help in this case. We serialize objects as follows:
>>
>> tile -> colony on that tile -> work locations in the colony
>>
>>
On 14.04.2013 03:06, Michael T. Pope wrote:
> On Sat, 13 Apr 2013 03:37:15 PM Michael Vehrs wrote:
>
>> Using the name option helps. I think I have sorted out the main
>> compatibility problem. At least units seem to be producing stuff.
>>
> Confirmed, and
On 14.04.2013 04:48, Michael T. Pope wrote:
> On Sat, 13 Apr 2013 10:44:08 AM Michael Vehrs wrote:
>
>> net.sf.freecol.common.networking.ServerAPI askExpecting
>>
>>WARNING: Received error response: server.alreadyStarted/
>>Sat Apr 13 07:49:34 GM
On 13.04.2013 12:59, Michael T. Pope wrote:
> On Sat, 13 Apr 2013 10:44:08 AM Michael Vehrs wrote:
>
>> net.sf.freecol.common.networking.ServerAPI askExpecting
>> WARNING: Received error response: server.alreadyStarted/
>> Sat Apr 13 07:49:34 GMT 201
On 07.04.2013 13:38, Michael T. Pope wrote:
> On Sun, 7 Apr 2013 09:12:14 AM Michael Vehrs wrote:
>
>> On 29.03.2013 13:25, Michael T. Pope wrote:
>>
>>> On Fri, 29 Mar 2013 10:01:57 AM Michael Vehrs wrote:
>>>
>>>> As far as I
On 29.03.2013 13:25, Michael T. Pope wrote:
> On Fri, 29 Mar 2013 10:01:57 AM Michael Vehrs wrote:
>
>> As far as I can tell, the generalized production code mostly works.
>>
> The backward compatibility is flakey. If I bring up my standard test game
> none of
On 01.04.2013 12:19, Michael T. Pope wrote:
> On Mon, 1 Apr 2013 11:50:19 AM you wrote:
>
>> I think
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
> A
On 01.04.2013 05:04, Michael T. Pope wrote:
> I have a schema problem. If we are transitioning from using "ID" to
> "id", we need to accept both for the time being. However I do not see
> how to express this in the schema. In the absence of a better idea,
> currently I am doing something like th
On 29.03.2013 13:25, Michael T. Pope wrote:
> On Fri, 29 Mar 2013 10:01:57 AM Michael Vehrs wrote:
>
>> As far as I can tell, the generalized production code mostly works.
>>
> The backward compatibility is flakey. If I bring up my standard test game
> none of
As far as I can tell, the generalized production code mostly works.
However, it is only used for calculating the actual production at the
moment. Any number of methods that calculate the potential production of
tiles, tile types, unit types and so on still use the old production
code. I intend
I have switched ColonyTile to the new production scheme. This change
introduces a slight semantic change. In the past, colony center tiles
had an explicit primary and secondary production, which were handled
slightly differently. Artificial tile improvements applied to the
primary but not to th
On 16.03.2013 10:08, Michael T. Pope wrote:
> On Sat, 16 Mar 2013 08:07:12 AM Michael Vehrs wrote:
>
>> There have been several complaints about the ability to open some panels
>> or dialogs several times.
>>
> Like BR#2141.
>
>
>> In some cases
There have been several complaints about the ability to open some panels
or dialogs several times. In some cases, it makes sense, I think. In
others, not so much. In the distant past, FreeCol had only a single
instance of most panels, all of which were created when the game
started, as far as I
On 11.03.2013 01:07, Michael T. Pope wrote:
>
> On Sun, 10 Mar 2013 03:33:45 PM Michael Vehrs wrote:
>
> > We have fine-tuned the order in which modifiers are applied to such
> a degree
>
> > that adding unattended production before or after the application of
>
On 25.02.2013 11:50, Michael T. Pope wrote:
>
> On Sun, 24 Feb 2013 04:34:42 PM Michael Vehrs wrote:
>
> > Well, I have implemented most of that now. Of course, it turns out there
>
> > is yet another problem which I did not see immediately, namely the
>
> > "
On 26.02.2013 17:43, Michael Vehrs wrote:
> On 25.02.2013 11:50, Michael T. Pope wrote:
>
>> On Sun, 24 Feb 2013 04:34:42 PM Michael Vehrs wrote:
>>
>>
>>> Well, I have implemented most of that now. Of course, it turns out there
>>>
>&
On 25.02.2013 11:50, Michael T. Pope wrote:
>
> On Sun, 24 Feb 2013 04:34:42 PM Michael Vehrs wrote:
>
> > Well, I have implemented most of that now. Of course, it turns out there
>
> > is yet another problem which I did not see immediately, namely the
>
> > "
On 23.02.2013 10:35, Michael Vehrs wrote:
> I have been trying to improve support for generalized production. As
> usual, things turn out to be more complicated than I had anticipated,
> much like in real life. In particular, I don't know how to handle this
> situation:
>
>
I have been trying to improve support for generalized production. As
usual, things turn out to be more complicated than I had anticipated,
much like in real life. In particular, I don't know how to handle this
situation:
Now let's assume a 50% production modifier for hammers, due to expe
On 12.02.2013 13:35, Michael T. Pope wrote:
> On Mon, 11 Feb 2013 04:35:49 PM Michael Vehrs wrote:
>
>> I admit I did not explain that properly. Some time ago, there was an
>> improvement request, either on the tracker or the developer list, to
>> allow switching the
On 11.02.2013 10:07, Michael T. Pope wrote:
> On Sun, 10 Feb 2013 01:56:43 PM Michael Vehrs wrote:
>
>> I have committed a change that introduces a new generalized production
>> element, but does not yet make use of its new features. I tried to
>> preserve compatib
On 10.02.2013 01:18, Jonathan Simona wrote:
> I think that I finally solved, well pretty much solved, the minimap
> bug. I cut down much of the formula to just the bare minimum but still
> had to keep 1 magic number because it was part of the original code.
> My patch acceptance is due this Mond
I have committed a change that introduces a new generalized production
element, but does not yet make use of its new features. I tried to
preserve compatibility as far as possible. However, this might be a good
time to standardize all elements that wrap AbstractGoods in some way or
other. Any o
>
> I have to macs but nothing on me at the moment what do you need tested?
>
Nothing right now, but after a revamp of the installer config, it would
be nice to test the jar installer and the Mac bundle.
Regards
Michael
> -Original Message-----
> From
>
> On Sat, 9 Feb 2013 09:33:12 AM Michael Vehrs wrote:
>
>> No, it didn't. But the manual describes how to do that. I will update
>> the dist targets as time permits and hope to fix this along the way.
>> However, I don't know whether I will be able
On 08.02.2013 10:31, Michael T. Pope wrote:
> On Fri, 8 Feb 2013 08:29:26 AM Michael Vehrs wrote:
>
>> I have created an improvement request in the IzPack bugtracker. Maybe
>> something will come of it.
>>
> Indeed. So do you know if the izPack upgrade fixed
On 05.02.2013 09:48, Michael T. Pope wrote:
> On Tue, 5 Feb 2013 08:24:21 AM Michael Vehrs wrote:
>
>> Unfortunately, that didn't work. Unless I hear from the IzPack
>> developers, the only viable option seems to be to patch
>> com.izforge.izpack.util.os.Unix_Shor
On 05.02.2013 10:02, Michael T. Pope wrote:
> How do we want to manage the XDG (BR#2419) fix? There are compliance
> and transition issues to decide. The relevant compliance issues are:
>
> 1. freedesktop.org want user specific data stored in $XDG_DATA_HOME
> (defaults to $HOME/.local/share).
>
>
>
>> On Tue, 5 Feb 2013 08:24:21 AM Michael Vehrs wrote:
>>
>>> Unfortunately, that didn't work. Unless I hear from the IzPack
>>> developers, the only viable option seems to be to patch
>>> com.izforge.izpack.util.os.Unix_Shortcut. However, thi
On 03.02.2013 00:31, Tyler Viles wrote:
> My name is Tyler, I am a Java game developer, and I would love to
> contribute to the development of freecol.
>
We are always looking for new developers. Just download the code (we use
git now), pick a bug or small feature to implement, and get started.
On 05.02.2013 06:47, Michael Vehrs wrote:
> On 04.02.2013 09:47, Michael T. Pope wrote:
>
>> On Mon, 4 Feb 2013 08:25:02 AM Michael Vehrs wrote:
>>
>>
>>> The IzPack way is to write a desktop entry template for every supported
>>>
>&g
On 04.02.2013 09:47, Michael T. Pope wrote:
>
> On Mon, 4 Feb 2013 08:25:02 AM Michael Vehrs wrote:
>
> > The IzPack way is to write a desktop entry template for every supported
>
> > language... However, there does not seem to be any way to include
> multiple >
1 - 100 of 231 matches
Mail list logo
