On Sat, 04 Mar 2006 10:09:40 +0100
Frederic Bouvier <[EMAIL PROTECTED]> wrote:

> Curtis L. Olson a écrit :
> > Frederic Bouvier wrote:
> >
> >> I am trying to integrate this contribution in the code base but after
> >> too much hours spent on this, I finally won't. Three reasons :
> >>
> >> - it doesn't compiles under MSVC, for obscure reason I don't understand.
> >> - there are a lot of files for the base package that are not strictly
> >> needed at run times : lots of .xcf files ( gimp source ), xml files that
> >> are not property files, xsl files.
> >> - it doesn't use the present convention of being included in a single
> >> directory : separated extern texture directory, Assembly (?) directory.
> >>
> >> So I left to others the choice of including it or not. This patch is not
> >> straightforward ( lots of template, imbrication level and inlines of all
> >> sort, including the use of function pointers to inline code ) and
> >> requires a lot of time to sort things out.
> >>  
> >>
> >
> > Hi Fred,
> >
> > Thanks for taking such a detailed look at the source.  As a general
> > rule, we do our best to include contributions, but there are times
> > where patches simply can't be applied in their current form.  We feel
> > bad about it, we hate to see wasted work, but it occasionally happens
> > and can happen for a variety of reasons.
> >
> > I've seen everything from "I didn't know what that section of code did
> > so I deleted it", to "this patch is mostly broke, but I expect you'll
> > seek out, debug, and fix all the problems", all the way up to huge
> > massive patches that touch darn near every file in the project in a
> > variety of scary and hard to decipher ways.
> >
> > Gimp source isn't necessarily bad because it allows others to more
> > easily edit the graphics, but they can burn a lot of space.
> >
> > Perhaps this developer would be willing to work with the core
> > developers to make what ever changes are needed so the patch is
> > acceptable (such as more closely following existing conventions and
> > making code changes so we don't break any cross platform portability.)
> 
> Hello Jean-Yves,
> 
> Night bringing advice, I fixed the MSVC issues and also fixed other bugs
> reported by the compilers, or by segfaults
> I also moved the assembly directory inside the mk-viii directory to keep
> things encapsulated.
> 
> 
> My changes are in this file : 
> http://frbouvi.free.fr/flightsim/mk-viii-fb.tar.gz
> 
> If you agree with them, just tell me and I will commit them.

Here are my comments:

  - I've placed assembly directly under the Instruments-3d directory
    because it is not specific to the MK VIII; I'm however unsure
    whether such cockpit assemblies are used for other purposes than
    managing a GPWS or not; feel free to keep your modification

  - Similarly, I've placed the GPWS textures directly beneath
    Instruments-3d because they are not specific to the MK VIII;
    however, since there's no other GPWS in the tree, you might want to
    keep your change

  - Doh:

        -         if (fabs(mk_data(localizer_deviation_dots).get() <= 2))
        +         if (fabs(mk_data(localizer_deviation_dots).get()) <= 2)

    Good catches. :)

  - I imagine that the other code changes are needed on MSVC and I'm
    not going to question them.

Feel free to commit; thanks for your work.

PS: some documentation should follow relatively soon.

-- 
Jean-Yves Lefort

[EMAIL PROTECTED]
http://lefort.be.eu.org/

Attachment: pgpWICUNEn1Pf.pgp
Description: PGP signature

Reply via email to