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 not that serious as I read it, right ?
I don't know how you
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 not that
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
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
against
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 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 look.
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 second
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 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 random
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:
- Houses
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,
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.
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 started on
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 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 a
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 29010KT 10SM
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
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.
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
19 matches
Mail list logo
