Hi Stuart,
> Failed to set alias to /controls/refuelling/refuelling-drogues-pos-norm
I think I've seen that with all aircraft I've flown recently. IIRC they were
all non-AAR capable (as in, they had no AAR stuff in -set.xml) but I'm not near
my computer, so I cannot confirm that theory.
Cheers,
Gijs
> Date: Wed, 8 May 2013 10:56:25 +0100
> From: stuar...@gmail.com
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] 2.10.1
>
> On Fri, May 3, 2013 at 6:15 PM, Vivian Meazza wrote:
> > I re-installed the Jenkins nightly Win build from yesterday – seems OK,
> > although I have NOT done any extensive testing. I’m seeing regular crashes
> > here from ALS and Rembrandt, but that’s nothing new. I’m getting a number
> > of errors on start-up; they seem harmless:
> >
> > Failed to create alias at
> > /controls[0]/refuelling[0]/refuelling-drogues-pos-norm
> >
> > [0]. Source /sim[0]/multiplay[0]/generic[0]/float[2] is already aliasing
> > another
> >
> > property.
> >
> > Failed to set alias to /controls/refuelling/refuelling-drogues-pos-norm
>
> FYI, I don't think this is related to the AAR work I've done recently, and
> looks
> like it might be aircraft specific. What aircraft are you seeing this with?
>
>
> > I would be more concerned over the state of the data. The reinstall has
> > partly solved the Screenshot directory issue – it now uses the default
> > Working Directory, but the gui input is still stuck. We have a small glitch
> > with Stuart’s latest iteration of the Random Vegetation (aka trees) with
> > what I think is probably a mipmapping issue.
>
> I thought 2.10.1 data would be taken from 2.10.0, with commits cherry-picked?
>
> If not, I'd suggest backing out that commit from the 2.10.1 data branch, as
> it has a co-requisite simgear change, and as Vivian mentions still has
> some issues.
>
> I've been away for the last 5 days so haven't had the chance to look into
> the tree problem further, but have a couple of ideas. One option would be
> to "mirror" the texture rows, so instead of looking like this:
>
> ^^^^^^^
> ^^^^^^^
> ^^^^^^^
> ^^^^^^^
>
> It would be top-to-top and base-to-base:
>
> vvvvvvvv
> ^^^^^^^^^
> vvvvvvvv
> ^^^^^^^^
>
> That way is the mipmap UV isn't quite accurate, it would just include the
> tree-top of the texture above, rather than the base. This would certainly be
> less noticeable. The downside is that I think it would require adding an if()
> test to the vertex shader, something I've been avoiding due to (unfounded?)
> concerns about performance.
>
> Or I might simply change the textures to a (very) long strip, so instead of
> 512x128 it would be 2048x128. However that feels rather clunky, and might
> not make good use of GPU memory. Anyone with GPU experience care to
> comment?
>
> -Stuart
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. This 200-page book is written by three acclaimed
> leaders in the field. The early access version is available now.
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
