Re: [Freecol-developers] FreeCol 0.10.6 has been released
On Thu, 3 Jan 2013 10:01:40 AM Michael T. Pope wrote: >[Strageness with matchesNull and getModifierSet] > The more I look at this one the more worrying it looks. Pretty much > anything involving modifiers ends up in that routine, and I really like > being able to trust that the spec means what it says. I will have a closer > look at this soon. Ah. I have convinced myself the test suite was in error. Tile.potential(grain, null) was indeed incorrectly including the bonus marked with matchesNull=false. I have fixed the broken test, added a test that calls Tile.potential(grain, expertFarmer) which correctly does pick up that bonus, and removed the null-object-accepts-all-modifiers code in getModifierSet (svn.10436). This remains a scary fundamental change, but there are four current instances of matchesNull=false in the spec, for the expert farmer and fisherman on bonus resources, which appear to still be working correctly. Cheers, Mike Pope signature.asc Description: This is a digitally signed message part. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] FreeCol 0.10.6 has been released
On Wed, 2 Jan 2013 04:33:21 PM Michael Vehrs wrote:
> On 02.01.2013 11:29, Michael T. Pope wrote:
> > On Sat, 29 Dec 2012 08:25:20 PM Michael T. Pope wrote:
> >> On Sat, 29 Dec 2012 09:53:28 AM Michael Vehrs wrote:
> Then for now how about we just rename the existing basicProduction as
> basicPerUnitProduction and add a new field for the non-unit production.
> >>>
> >>> I had this idea, too. For the sake of compatibility, I think it would be
> >>> better to keep the (misleading) name basicProduction and introduce a new
> >>> field with a new name for non-unit production, however. In fact, why not
> >>> call it nonUnitProduction?
> >>
> >> OK, lets go with that for now. I fear the backward compatibility code is
> >> going to be awkward either way.
> >
> > Actually, I think we can get most of the way with scopes. Or at least we
> > can get closer now that I have fixed them to work with modifiers attached
> > to Buildings (svn.10433). If Buildings then calculate bonuses with
> > getModifierSet(... ...) for the units present and
> > getModifierSet(...>
> > ...) for the building itself, then something like:
> > >
> > produces="model.goods.bells">
> >
> >
> >
> >
> >
> >
> >
> > should work. (Although not so well with the crosses situation, unless a
> > model.building.cathedral matches a)
>
> That won't work. You either need to use several scopes, or introduce an
> ability and use a scope with that.
OK. Perhaps I should take my own suggestion upthread and see if the
autoproduction functionality would work in these cases.
> > [Aside: while digging into this, I was trying to use a matchesNull="false"
> > scope attribute, which did not appear to work. Deep inside
> >
> > FeatureContainer.getModifierSet() we have:
> > if (fcgot == null) {
> >
> > result.addAll(modifierSet);
> >
> > } else {
> >
> > for (Modifier modifier : modifierSet) {
> >
> > if (modifier.appliesTo(fcgot, turn))
> > result.add(modifier);
> >
> > }
> >
> > }
> >
> > which looks like that if the object (fcgot) is null then all the modifiers
> > are just accepted, and thus a matchesNull test will never get a chance to
> > fail. I tried dropping the null test case, but that broke a tile
> > production test, which (surprise) is the only place current where
> > matchesNull=false is relevant, so either I am wrong, or we have two other
> > problems:-S.]
>
> At the very least, it is confusing. Twice, at least, I meant to revamp
> the scopes and limits to use something more like standard predicate
> logic, but I never got around to it. Maybe this year...
The more I look at this one the more worrying it looks. Pretty much anything
involving modifiers ends up in that routine, and I really like being able to
trust that the spec means what it says. I will have a closer look at this
soon.
> > Fixing things with spec changes is of course not going to work for
> > existing
> > saved games. In future should we think about adding a version to the spec
> > and auto-upgrade specs seen in saved games, or is that getting too
> > intrusive?
>
> That way lies madness, in my opinion.
OK. No in-game spec upgrades is the policy. Mods are confusing enough as it
is (speaking of which, as of svn.10428, user mods should be working again).
Cheers,
Mike Pope
signature.asc
Description: This is a digitally signed message part.
--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 ___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] FreeCol 0.10.6 has been released
On Wed, 2 Jan 2013 04:19:32 PM Michael Vehrs wrote: > At any rate, the re-write of tile styles has paved the way for > using an arbitrary number of equivalent tiles. We might also break down > our tiles into smaller sub-tiles, or use alpha blending for tile boundaries. I do not doubt the former would help, but I reckon the latter is more likely to be the big win. IMHO the map already looks quite good, but the best thing we can do to improve its general appearance would be to reduce the sharpness of the tile transitions. I have played enough chess:-). Cheers, Mike Pope signature.asc Description: This is a digitally signed message part. -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] Fortresses don't seem to require minimum population
On Wed, 2 Jan 2013 03:53:44 PM Russell Steinthal wrote: > Thanks for committing so quickly! Your report made a very clear and verifiable case that there was a problem. If only they were all as easy:-). > FWIW, I think I actually have a copy of Col1 on 3.5" floppy disks in one of > my many piles, in which case I could potentially try to see what the > behavior was. There are many (> 20) bugs blocked because it is unclear what Col1 did. There is plenty of opportunity for anyone who can run Col1 to make a really useful contribution. The `so what did the arsenal really do?' question is just one of the recent sore points. > OTOH, I don't know that I still have a working PC with a > 3.5" floppy drive. :) Binaries apparently exist on the net. The fact that you have a physical copy in your possession may mean it is legal for you to use one in your jurisidiction. Cheers, Mike Pope signature.asc Description: This is a digitally signed message part. -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] Fortresses don't seem to require minimum population
Thanks for committing so quickly! I'm not sure how much time I'll have to contribute now that my Christmas-to-New Year's vacation has ended (and I have a backlog of coding to do on some of my own projects :)), but I'll at least take a look at the bug report and see what I can do. FWIW, I think I actually have a copy of Col1 on 3.5" floppy disks in one of my many piles, in which case I could potentially try to see what the behavior was. OTOH, I don't know that I still have a working PC with a 3.5" floppy drive. :) On Tue, Jan 1, 2013 at 5:15 PM, Michael T. Pope wrote: > 2871069 -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] FreeCol 0.10.6 has been released
On 02.01.2013 11:29, Michael T. Pope wrote:
> On Sat, 29 Dec 2012 08:25:20 PM Michael T. Pope wrote:
>
>> On Sat, 29 Dec 2012 09:53:28 AM Michael Vehrs wrote:
>>
Then for now how about we just rename the existing basicProduction as
basicPerUnitProduction and add a new field for the non-unit production.
>>> I had this idea, too. For the sake of compatibility, I think it would be
>>> better to keep the (misleading) name basicProduction and introduce a new
>>> field with a new name for non-unit production, however. In fact, why not
>>> call it nonUnitProduction?
>>>
>> OK, lets go with that for now. I fear the backward compatibility code is
>> going to be awkward either way.
>>
> Actually, I think we can get most of the way with scopes. Or at least we can
> get closer now that I have fixed them to work with modifiers attached to
> Buildings (svn.10433). If Buildings then calculate bonuses with
> getModifierSet(... ...) for the units present and
> getModifierSet(...
> ...) for the building itself, then something like:
>
> produces="model.goods.bells">
>
>
>
>
> should work. (Although not so well with the crosses situation, unless a
> model.building.cathedral matches a)
>
That won't work. You either need to use several scopes, or introduce an
ability and use a scope with that.
> [Aside: while digging into this, I was trying to use a matchesNull="false"
> scope attribute, which did not appear to work. Deep inside
> FeatureContainer.getModifierSet() we have:
>
> if (fcgot == null) {
> result.addAll(modifierSet);
> } else {
> for (Modifier modifier : modifierSet) {
> if (modifier.appliesTo(fcgot, turn))
> result.add(modifier);
> }
> }
>
> which looks like that if the object (fcgot) is null then all the modifiers are
> just accepted, and thus a matchesNull test will never get a chance to fail.
> I tried dropping the null test case, but that broke a tile production test,
> which (surprise) is the only place current where matchesNull=false is
> relevant, so either I am wrong, or we have two other problems:-S.]
>
At the very least, it is confusing. Twice, at least, I meant to revamp
the scopes and limits to use something more like standard predicate
logic, but I never got around to it. Maybe this year...
>
> Fixing things with spec changes is of course not going to work for existing
> saved games. In future should we think about adding a version to the spec and
> auto-upgrade specs seen in saved games, or is that getting too intrusive?
>
That way lies madness, in my opinion.
> Cheers,
> Mike Pope
>
Regards
Michael
--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] FreeCol 0.10.6 has been released
On 02.01.2013 00:00, Michael T. Pope wrote: > On Tue, 1 Jan 2013 02:01:05 PM Michael Vehrs wrote: > >> On 01.01.2013 12:37, Michael T. Pope wrote: >> >>> Fair enough. I remain in favour of automatic generation, but less happy >>> about the smoothness/regularity of the rivers and roads. >>> >> Do you mean automatic generation of the required images, or generation >> in-game? In the case of roads, we use the latter, in the case of rivers, >> the former. Of course, that might be changed, but I don't think we can >> generate pretty rivers in-game. >> > I was thinking of pre-generation. In-game is asking for latency problems. I > am somewhat surprised that roads are as quick as they are. > I must admit that I have no realistic idea of how fast image composition is compared to drawing Bezier curves. Neither in general, nor with regard to AWT. Some experiments might be in order. > >> If we generated the rivers in-game, we could do things like that, but >> we'd also have to take the river-and-forest problem into account. A >> straight river uses less space than a meandering river, which probably >> means that we would also need various forest tiles. >> > Disk is cheap:-). RAM is not quite as cheap. >In the long run I think we should expect to have multiple > forms of the same game-effective tile. That would break up the obvious > patterning in the ocean tiles without going as far as the suggestion to > animate them, and add some texture to the land. Autogeneration is the obvious > tool to get there without requiring an army of artists. > > Cheers, > Mike Pope > True enough. I'll think about this some more, and possibly try another tack. At any rate, the re-write of tile styles has paved the way for using an arbitrary number of equivalent tiles. We might also break down our tiles into smaller sub-tiles, or use alpha blending for tile boundaries. Regards Michael -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] FreeCol 0.10.6 has been released
On Sat, 29 Dec 2012 08:25:20 PM Michael T. Pope wrote:
> On Sat, 29 Dec 2012 09:53:28 AM Michael Vehrs wrote:
> > > Then for now how about we just rename the existing basicProduction as
> > > basicPerUnitProduction and add a new field for the non-unit production.
> >
> > I had this idea, too. For the sake of compatibility, I think it would be
> > better to keep the (misleading) name basicProduction and introduce a new
> > field with a new name for non-unit production, however. In fact, why not
> > call it nonUnitProduction?
>
> OK, lets go with that for now. I fear the backward compatibility code is
> going to be awkward either way.
Actually, I think we can get most of the way with scopes. Or at least we can
get closer now that I have fixed them to work with modifiers attached to
Buildings (svn.10433). If Buildings then calculate bonuses with
getModifierSet(... ...) for the units present and getModifierSet(...
...) for the building itself, then something like:
should work. (Although not so well with the crosses situation, unless a
model.building.cathedral matches a )
[Aside: while digging into this, I was trying to use a matchesNull="false"
scope attribute, which did not appear to work. Deep inside
FeatureContainer.getModifierSet() we have:
if (fcgot == null) {
result.addAll(modifierSet);
} else {
for (Modifier modifier : modifierSet) {
if (modifier.appliesTo(fcgot, turn)) result.add(modifier);
}
}
which looks like that if the object (fcgot) is null then all the modifiers are
just accepted, and thus a matchesNull test will never get a chance to fail.
I tried dropping the null test case, but that broke a tile production test,
which (surprise) is the only place current where matchesNull=false is
relevant, so either I am wrong, or we have two other problems:-S.]
Fixing things with spec changes is of course not going to work for existing
saved games. In future should we think about adding a version to the spec and
auto-upgrade specs seen in saved games, or is that getting too intrusive?
Cheers,
Mike Pope
signature.asc
Description: This is a digitally signed message part.
--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 ___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers
