On Mon, 6 May 2013 07:29:08 AM Michael Vehrs wrote:
> (but I'll have to check the bug reports individually)
My mistake, BR#2544 is just a duplicate of BR#2486 (fixed in trunk),
and nothing to do with production.
Cheers,
Mike Pope
signature.asc
Description: This is a digitally signed message par
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. What next?
>>>
>> I need to see if
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. What next?
>
> I need to see if (add one-liner, revert df63b36) still breaks the AI.
OK. My testing i
On Sat, 27 Apr 2013 03:56:58 PM Michael Vehrs wrote:
> I still need to look at the UI side, especially the production modifier
> tooltips. The next step would be to make production types selectable.
> This will have to be done using the testing specification, since this is
> not a feature of the or
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 the AI.
> If it is ok, are
On Sat, 27 Apr 2013 08:10:44 PM Michael T. Pope wrote:
> I need to see if (add one-liner, revert df63b36) still breaks the AI.
The test is queued for tonight. However looking at it again, df63b36 has
three main parts:
1. unrelated serialization cleanup
2. updateProductionType moved up from {Buil
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 the AI.
If it is ok, are you happy with the production system or is there more to
come?
C
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 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, I can figure out what I did wrong. However, I have
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 AI failure is just the downstream
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 AI failure is just the downstream symptom of
something more fundamental breaking, but I ran out o
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 expect.
>>>
>>>
>> Alas so. The AI perfor
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 still off.
> I tried something
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 still off.
I tried something a bit more incremental in git.df63b36, which works better
and doe
On Sun, 14 Apr 2013 04:24:39 PM Michael Vehrs wrote:
>>[name/owner issue]
> No, certainly not. It might be nice to add a dialog to allow the player
> to choose.
It might. I think I have fixed the underlying issue (git.90e938d0).
The owner attribute was not even being written.
>>[Work type fixup
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.userNameNotPresent/Player
>> "mike" is not presen
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
>>
>> Since the colony tiles surround the colony, so
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
>
> Since the colony tiles surround the colony, some of the work tiles will
> not have been serialized when
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.userNameNotPresent/Player
> "mike" is not present in the game.
>Known players = ( mpope model.nati
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 I am trying to sort out the name
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 GMT 2013
>>Thread ID: 12
>>
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 2013
> Thread ID: 12
I am having strife reproducing this. I tried a bunch of oth
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 I am trying to sort out the name/hang problem.
However, I am concerned by the null unit type pr
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 2013
>> Thread ID: 12
>>
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 2013
> Thread ID: 12
WTF. Well that is a new bug. Looks like the user connection hand
On Sat, 13 Apr 2013 09:51:22 AM Michael Vehrs wrote:
> Um, I can't even load that game. Is a special setup required?
No. Its just an autogenerated 0.10.5 1492 debug game that I have been using
as my standard quick loading test case for the last n months.
It loads for me ATM, with both trunk and
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 can tell, the generalized production code mostly work
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 the building production wor
On Fri, 29 Mar 2013 01:37:59 PM Michael Vehrs wrote:
>>["ID" goes away]
> The sooner the better. There are probably several things that should be
> cleaned up on flag day. Various elements based on abstract goods might
> be unified, and the same might be true for several different production
> elem
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 the building production wor
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 the building production works. The colony tiles look good though.
> However, it is only us
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 production (specifically, t
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 production (specifically, the secondary production)
> of the colony center tile fr
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 compatibility as far as possible. Howe
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 compatibility as far as possible. However, this might be a good
> time to standardize all ele
35 matches
Mail list logo
