FreeCol

Hi everybody,

We will now be switching to Java 1.5.

Please do not use static imports for any other class than
"java.lang.Math". We can make exceptions to this rule later, but it should
in that case be discussed. :-)

The constants we are using in the model (for type information) should not
be changed to enums, as we will be making Type-classes as part of the
0.7.0 release.


- Stian Grenborgen

Jorge Vargas wrote:
> On 12/7/06, Michael Burschik <Michael.Burschik@...> wrote:
>   
>> Jorge Vargas wrote:
>>     
>>> it seems that was fixed, I was wondering how can you set a specific
>>> scenario like that?
>>>
>>>       
> is the a way I can set the game to a specific state, in the case of
> that bug I'll have to set a lot of units which specific caracteristics
> in order to reproduce it.
>   
No, unfortunately you can't do that yet. In this case, however, 
reproducing the bug wasn't that important because it was more or less 
clear what might have caused it. At the beginning of a new turn, the 
unit's move allowance is set to a type-specific value, but if the unit's 
type changed during the turn, its movement allowance was not adjusted to 
its new type. Hence the bug.
>> I do not understand your question.
>>     
>>>> as does Feature Request #1607372, for example. In
>>>> the case of Feature Requests, it would be a good idea to ask the other
>>>> developers whether they agree with the request before implementing it.
>>>>
>>>>         
>>> that seems a little ambiguos does that means you "always" get tobacco planter??
>>>
>>>       
>> No, it doesn't. It says "a skill like Master Tobacco Planter", which
>> implies that this is an example. But bug reports and feature requests
>> are often vague, because the reporters are not acquainted with the code.
>> My own bug reports are often pretty vague if they concern areas of the
>> code I have not been working on.
>>
>>     
> ummm ok I hate bad bug reports :)
>   
Who doesn't? But they are the rule and not the exception. And 
personally, I didn't even think it bad. And we should remember that we 
all correspond and report bugs in English, but for most of us, English 
is not our native language. That makes it more difficult to describe the 
problem exactly.
>   
>> But my point is this: If you get a bug report or feature request like
>> this, you look at the code (that should be the map generator in this
>> case), figure out how things are done at the moment, how this might lead
>> to problems, and how things could be improved. So, have a look a
>> generateSkillForLocation and find a better solution.
>>
>>     
> ok thanks for the pointer I'll look into that
>
>   
Great.

Regards

Michael

> yes I totally agree I guess the pages can be rewriten inspired by the
original.
> Can you guys point me to the part of the code where all this is
> installed I did a quick grep on colonizopedia and didn't found it.

We can autogenerate the information about units, tiles etc when we have
performed the model restructuring scheduled for release 0.7.0. However,
information that cannot be added automatically would be a welcome
addition.

The code is located at:

net.sf.freecol.client.gui.panel.ColopediaPanel


- Stian Grenborgen

Stian Grenborgen wrote:
>> Bugs item #1610489, was opened at 2006-12-06 23:54
>> Summary: Exception using java 1.4.2 and freecol 0.5.3 - not playable
>>     
>
> I accidentally used a Java 1.5 class in the release we just made (0.5.3). :-(
>
> We have now two different choices: I can either fix the compatibility with
> Java 1.4 or we could just switch entirely to Java 1.5. It is really easy
> to fix the compatibility issue, and switching to 1.5 is something that I
> have wanted to discuss for some time now:
>
> According to the roadmap we will be releasing FreeCol 1.0 in November 2007
> - do you think there will be many Java 1.4 users left at that time? If
> not: it would be really nice to have the additional features 1.5 is
> providing (especially: annotations, generics and the new concurrency API).
>
>
> What do you think?
> - Stian Grenborgen
>
>
>   
I have no objections. It would be slightly easier for me, since there 
doesn't seem to be a 1.4 jdk for 64-Bit Linux on the Core2 Duo, and I 
have to use 1.5 anyway.

Regards

Michael

Stian Grenborgen wrote:
>> Well, we could make sure to mark the link as external. I thought of
>> putting the [W] wikipedia logo at the end of the paragraph and linking
>> it to the corresponding article. [...]
>>     
>
> Good idea! :-)
>
>   
Right, I'll do that then.
>   
>> This is not necessarily a problem, as long as we are aware of it. It
>> would mean changing the message generators, however. All new units would
>> have to send a message announcing their existence, for example. On the
>> other hand, we might want to see some messages generated by the units of
>> other players, especially during combat. In addition to "Dutch dragoon
>> has been promoted", you might want to see the corresponding "Spanish
>> artillery has been damaged", for example.
>>     
>
> Well, it would be really easy to cheat if we send messages about the
> creation of every unit.
>   
How would you cheat? I mean that every unit could send a message to its 
respective owner upon instantiation. The problem here is that the units 
do not know why they were created.
> I think sending the ModelMessages from the server to the clients might be
> an idea. We could have a visibility setting on the ModelMessages (this
> will be easier to implement after we have done the model restructuring
> scheduled for 0.7.0).
>
>
> - Stian Grenborgen
>
>   
Wouldn't the server send the message only to the owner of the unit? In 
this respect, nothing would have to change. It would even become easier 
for the client, which would no longer have to filter the messages.

Regards

Michael Burschik