Sébastien
Our posts have overlapped. These are now OK, but I still have the vertical
bands.
Thanks
Alan
-Original Message-
From: Sébastien MARQUE
Sent: Wednesday, September 14, 2011 8:04 PM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] ZKV1000 buildmaps.pl on W
Sébastien
Thanks for the quick response. I have done a git "pull" and am pleased to
report that the glob and mkdir errors have now disappeared. .-)
However I am still left with the three vertical bands as shown in my
previous post.
(http://v-twin.dynip.sapo.pt/alan/VickersAircaft/TSR2/maps/e00
Am 12.09.11 09:56, schrieb Alan Teeder:
> Google maps are notoriously incorrect on co-ordinates. Even their own road
> map overlay does not align perfectly with the scenery. You can check the
> accuracy yourself if you have a GPS receiver and visit a set of easily
> identifiable points like road ju
On Wed, 2011-09-14 at 15:13 +0100, Vivian Meazza wrote:
> Alasdair wrote:
>
> >
> > Hi all,
> > It always used to be that if no runway or parking ID is specified, a
> > runway facing into the wind will be chosen for takeoff. This no longer
> > happening. Tonight, with
> > METAR KSFO 140056Z 29010
Le 13/09/2011 20:38, Alan Teeder a ecrit :
> 1. At line 22 I had to change
>
> if ($OS eq 'Windows_NT') {
> $originalMapsDir =~ s:\\:/:g;
> @originalTiles = glob("\"$originalMapsDir/*.$imageFormat\"");
>
> to
>
> if ($OS eq 'Windows_NT') {
> $originalMapsDir =~ s:\\:/:g;
> @originalTiles =<$origin
Hi Alan,
I'm the author of buildmap.pl script. Hope not being too late.
I've no windows box here, but I had a WinXP on a virtual machine, which
I've used to test the script (not have it anymore though). AFAIR it
worked quite well on the VM but it was a long time ago and I don't
remeber if my t
On 14 Sep 2011, at 14:34, Scott wrote:
> I'm playing around with extending the NasalSys.cxx navinfo() function that
> torsten wrote.
> >From what I can tell it calls navlist.cxx findByIdentAndFreq(position,
> >ident, freq, type)
> which then calls findByIdentAndFreq(ident, freq, type) and does
Alasdair wrote:
>
> Hi all,
> It always used to be that if no runway or parking ID is specified, a
> runway facing into the wind will be chosen for takeoff. This no longer
> happening. Tonight, with
> METAR KSFO 140056Z 29010KT 10SM FEW006 18/12 A2997 RMK AO2 SLP149
> T01830122, I am always start
I'm playing around with extending the NasalSys.cxx navinfo() function
that torsten wrote.
>From what I can tell it calls navlist.cxx findByIdentAndFreq(position,
ident, freq, type)
which then calls findByIdentAndFreq(ident, freq, type) and does a
distance filter on the result.
The problem is the
On Wed, Sep 14, 2011 at 12:58 PM, James Turner wrote:
>
> On 14 Sep 2011, at 12:00, Stuart Buchanan wrote:
>
>> OK. We've got something similar already in the C code for exactly this
>> purpose. Might be more efficient to simply expose that over Nasal, but
>> I'm not sure how easy that would actual
Hi
anyone can tell me how to change scenery textures? As they are so beautiful,
sigh, I want to change
to maybe some google texture i have or other alike Switzerland pro etc.
How was Brest done? I see the materials added but wonder about the changes in
*.stg files.
Thanks-
On 14 Sep 2011, at 12:00, Stuart Buchanan wrote:
> OK. We've got something similar already in the C code for exactly this
> purpose. Might be more efficient to simply expose that over Nasal, but
> I'm not sure how easy that would actually be.
Pretty trivial, for a function such as sg_random, unl
On Wed, 2011-09-14 at 13:33 +0200, Andreas Gaeb wrote:
> Am 14.09.2011 11:43, schrieb Erik Hofman:
> > I've been pushing this behavior various times and scenery objects should
> > always be positioned at the same location over and over again.
> To clarify things up a bit, not all is broken:
> - Hou
Am 14.09.2011 11:43, schrieb Erik Hofman:
> I've been pushing this behavior various times and scenery objects should
> always be positioned at the same location over and over again.
To clarify things up a bit, not all is broken:
- Houses etc. are the same
- Trees are at the same location and same s
On Wed, Sep 14, 2011 at 11:18 AM, Thorsten Renk wrote:
>> Thorsten Renk - If this something we need to be thinking about for the
>> Local Weather as well?
>
> We've been tossing the idea around in the forum that Local Weather stops
> using the rand() function from Nasal and uses its own internal r
> Thorsten Renk - If this something we need to be thinking about for the
> Local Weather as well?
We've been tossing the idea around in the forum that Local Weather stops
using the rand() function from Nasal and uses its own internal random
number generator. In this way, it could be initialized in
On Wed, Sep 14, 2011 at 10:31 AM, Jörg Emmerich wrote:
> 1) Writer, Poet, Engineering, Marketing, etc.
> Most of those surely do not want to be bothered with the final looks of
> their design - but surely some do (and then run into problems).
(I think the Marketing person here is part of the secon
On Wed, Sep 14, 2011 at 10:43 AM, Erik Hofman wrote:
> Is this broken.. again?
> Sigh.
>
> I've been pushing this behavior various times and scenery objects should
> always be positioned at the same location over and over again.
This may just be broken in the default 3D clouds code. I'll take a lo
On Wed, 2011-09-14 at 11:18 +0200, Andreas Gaeb wrote:
> Hello everybody,
>
> lately I've been working on a multiscreen setup driven by multiple host
> machines. In order to get the same random scenery objects, all machines
> need to use the same random seed. Up to now, the random seed is taken
On Tue, 2011-09-13 at 11:46 +0300, thorsten.i.r...@jyu.fi wrote:
> LaTeX is not a word processor, it is a professional typesetting tool. I
> don't know about fiction books, but the vast majority of science books you
> can buy is done with LaTeX. If you know how to work with it (rather than
> agains
Hello everybody,
lately I've been working on a multiscreen setup driven by multiple host
machines. In order to get the same random scenery objects, all machines
need to use the same random seed. Up to now, the random seed is taken
from system time, which leads to inconsistencies.
The attache
Am 14.09.11 08:58, schrieb thorsten.i.r...@jyu.fi:
>>> LaTeX is not a word processor, it is a professional typesetting tool.
>>
>> I see all the reasons to keep the docs in LaTex (like keeping the
>> process efficient at the moment), but this sentence here about
>> "professional tools" is probably
22 matches
Mail list logo
