gerard robin wrote:
> On mardi 05 mai 2009, Alexis Bory - xiii wrote:
> > I still don't know if it's ok to let the pushback stuff in the Nasal dir.
> > IMHO this should be further discussed.
>
> Won't it be better to have it within Aircraft/Generic ?
> with others stuffs like aar or radar
I
On mardi 05 mai 2009, Alexis Bory - xiii wrote:
> Alexis Bory wrote:
> > Update of /var/cvs/FlightGear-0.9/data/Nasal In directory
> > baron.flightgear.org:/tmp/cvs-serv9196
> >
> > Modified Files: pushback.nas Log Message: - Now the pushback "door"
> > will be created only if /sim/model/pushba
Alexis Bory wrote:
> Update of /var/cvs/FlightGear-0.9/data/Nasal In directory
> baron.flightgear.org:/tmp/cvs-serv9196
>
> Modified Files: pushback.nas Log Message: - Now the pushback "door"
> will be created only if /sim/model/pushback has already been created
> by the modeler via the -set.x
* Melchior FRANZ -- Monday 16 March 2009:
> + vary callsign & TACAN id
> + fly refueling pattern
That's now done. The tanker flies a refueling pattern with length
50 nm and 25 degree turns. You get a warning 1 nm before the turn.
Note that pilots also tank during the turn!
Bank angle and turn rat
* gerard robin -- Thursday 19 March 2009:
> I can only answer that i never had any problem with the actual AI/MP radar,
> it is very flexible , since the main required values x-shift, y-shift, in
> addition to the other useful aircraft data ( range-nm, altitude, heading )
> are there. These da
On jeudi 19 mars 2009, Melchior FRANZ wrote:
> * gerard robin -- Thursday 19 March 2009:
> > Then, do you mean that the old "Radar Fashion" will be removed,
> > what a pity.
>
> I haven't planned that (yet). But in the long run it should get
> removed. This was an early mechanism to get the brand-n
* gerard robin -- Thursday 19 March 2009:
> Then, do you mean that the old "Radar Fashion" will be removed,
> what a pity.
I haven't planned that (yet). But in the long run it should get
removed. This was an early mechanism to get the brand-new AI
models on the screen (for the T38?), and that was
On jeudi 19 mars 2009, Melchior FRANZ wrote:
> * gerard robin -- Thursday 19 March 2009:
> > With the usual AI tankers we have a lot of data regarding the Radar
> > x-shift y-shift in-range , rotation, v-offset, .. and so on
> >
> > That tanker feature don't gives such information , it i
* gerard robin -- Thursday 19 March 2009:
> With the usual AI tankers we have a lot of data regarding the Radar
> x-shift y-shift in-range , rotation, v-offset, .. and so on
>
> That tanker feature don't gives such information , it is missing ,
> is it any valuable reason ?
That's not
On lundi 16 mars 2009, Melchior FRANZ wrote:
> While we are at it, here some comments on tanker.nas:
>
> There's a menu entry AI/MP->Tanker, which opens a small dialog where
> you can request a tanker. It'll contact you and tell you something
> like this:
>
> "MOBIL3 at 15000, heading 130 with 25
While we are at it, here some comments on tanker.nas:
There's a menu entry AI/MP->Tanker, which opens a small dialog where
you can request a tanker. It'll contact you and tell you something
like this:
"MOBIL3 at 15000, heading 130 with 250 knots, TACAN 062X"
At the moment TACAN is always 062X,
On dimanche 15 mars 2009, Melchior FRANZ wrote:
> * gerard robin -- Sunday 15 March 2009:
> > => make sure /systems/refuel/ exists <=
> >
> > Since a specific AAR could use any other specific property
>
> This should have been "systems/refuel", without the leading
> slash. It's the tanker's prop
* gerard robin -- Sunday 15 March 2009:
> => make sure /systems/refuel/ exists <=
>
> Since a specific AAR could use any other specific property
This should have been "systems/refuel", without the leading
slash. It's the tanker's property /ai/model/tanker[*]/refuel/contact.
This is the one and
On dimanche 15 mars 2009, Melchior FRANZ wrote:
> * gerard robin -- Sunday 15 March 2009:
> > You should know that aircrafts which have some specific AAR won't
> > be able to use it.
>
> All that work(ed) with the tanker scenarios should also work with
> this. It doesn't do anything magic. Just off
* gerard robin -- Sunday 15 March 2009:
> You should know that aircrafts which have some specific AAR won't
> be able to use it.
All that work(ed) with the tanker scenarios should also work with
this. It doesn't do anything magic. Just offer a tanker and set
the aircraft's "contact" flag if it's c
If that is . right
=> allow aar-equipped aircraft to request a tanker everywhere without
scenario <==
You should know that aircrafts which have some specific AAR won't be able to
use it.
--
Gérard
http://pagesperso-orange.fr/GRTux/
J'ai décidé d'être heureux parce que c'est bon pour la
On 17 Dec 2008, at 15:44, Syd wrote:
> I dont know if this makes sense to anyone else , but to me the first
> version is a word , the second option is a sentence :)
Agreed completely - the issue is, I think of all these things as
sentences (well, phrases, anyway) - so I find FOO2BAR rather lik
Melchior FRANZ wrote:
> * James Turner -- Wednesday 17 December 2008:
>
>>> + var KT2MPS = 0.51; # knots to m/s
>>>
>
>
>> Personally I think all these constants would be easier to
>> read if they were written the same way as the Simgear ones,
>> i.e MPS_TO_KT, NM_T
Melchior FRANZ wrote:
> var MPS_TO_KT = MPS2KT;
>
> What do other Nasal developers think? I'm willing to change it if
> others have problems with that, too. (And to change all occurrences
> in the repository.)
No problem here with shorter names for the constants. For me they are
easy to reco
Melchior FRANZ wrote:
> * James Turner -- Wednesday 17 December 2008:
> > > + var KT2MPS = 0.51; # knots to m/s
>
> > Personally I think all these constants would be easier to
> > read if they were written the same way as the Simgear ones,
> > i.e MPS_TO_KT, NM_TO_M and so on.
* James Turner -- Wednesday 17 December 2008:
> > + var KT2MPS = 0.51; # knots to m/s
> Personally I think all these constants would be easier to
> read if they were written the same way as the Simgear ones,
> i.e MPS_TO_KT, NM_TO_M and so on.
I find them equally easy to read
On 17 Dec 2008, at 01:03, Melchior Franz wrote:
> + var KT2MPS = 0.51; # knots to m/s
> + var MPS2KT = 1 / KT2MPS;
> +
> var LB2KG = 0.45359237;# pounds to kilogram
> var KG2LB = 1 / LB2KG;
Personally I think all these constants would be easier to read if th
On 25 Sep 2008, at 15:32, Melchior FRANZ wrote:
>> I see you don't like my long_underscored_function_names [...]
>
> That's because we don't have a single function name with underscores.
> It's setprop, not set_prop. It's settimer, not set_timer, etc. It's
> about consistency.
Okay - is there a
* James Turner -- Wednesday 24 September 2008:
> Well, in the future, the key args for getActiveRunwayForUsage are what
> I said - the usage type (landing or takeoff, maybe some other flags in
> the future for weird stuff, like helis) and the inbound / outbound
> radial, [...]
OK, then let's
In my experience the active runway is designated by the ground radio
station at the field. At small fields it is the same active runway for
take-off and landing. At large busy fields these might be two
different (often parallel) runways. If different non-parallel runways
are designated, they w
On 24 Sep 2008, at 11:30, Melchior FRANZ wrote:
> The airportinfo() function is there to return everything that you
> ever wanted to know about an airport, and more. Active takeoff and
> landing runway belongs there. What "other optional args" would
> we need? More than required minimum length/wi
* James Turner -- Wednesday 24 September 2008:
> This could either be an addition member on the airport hash
yes
> [...] a new function exposed to Nasal makes sense [...]
IMHO no
>active_runway_for_airport(, ... other optional args )
The airportinfo() function is there to return
On 24 Sep 2008, at 09:38, James Turner wrote:
> Thanks Melchior - I forget to do some searches in data/ when I updated
> this interface.
Also, just noticed this (in char-menu.xml) :
# Determine the active runway. We have two ways to do this:
# - If the aircraft is on the ground (o
On 23 Sep 2008, at 21:08, Melchior Franz wrote:
> Modified Files:
> glide_slope_tunnel.nas
> Log Message:
> - remove no longer neede complement_runways() function
> - s/threshold1/threshold/
Thanks Melchior - I forget to do some searches in data/ when I updated
this interface.
James
-
Melchior FRANZ wrote:
> * Martin Spott -- Tuesday 08 May 2007:
> > Is this intended to implement toe-brakes ? I thought we
> > already had these,
[...]
> What the new singleton class implements is differential braking
> via toe-brake-less pedals. I learned that many British military
> aircraft have
* Martin Spott -- Tuesday 08 May 2007:
> Is this intended to implement toe-brakes ? I thought we
> already had these,
No and yes. We do indeed have toe brakes since a long time:
, and . on the keyboard, or two separate js buttons, or real
toe brakes on pedals.
What the new singleton class impleme
Hi Melchior,
Melchior Franz wrote:
> Update of /var/cvs/FlightGear-0.9/data/Nasal
> In directory baron:/tmp/cvs-serv28789
>
> Modified Files:
> aircraft.nas
> Log Message:
> add class that implements differential braking with rudder input
I'm not good in parsing Nasal source, so I'm not
Hi,
hm, maybe it's not solved fully. I got it again :-(
Maik
Maik Justus schrieb am 06.02.2007 16:52:
> Hi Melchior,
>
> by updating data without updating the source the spinning bug is gone.
>
> Thanks!
> Maik
>
>
> Melchior Franz schrieb am 06.02.2007 15:34:
>
>> Update of /var/cvs/FlightGe
Hi Melchior,
by updating data without updating the source the spinning bug is gone.
Thanks!
Maik
Melchior Franz schrieb am 06.02.2007 15:34:
> Update of /var/cvs/FlightGear-0.9/data/Nasal
> In directory baron:/tmp/cvs-serv15580
>
> Modified Files:
> dynamic_view.nas
> Log Message:
> - fi
Melchior Franz wrote:
> Update of /var/cvs/FlightGear-0.9/data/Nasal
> In directory baron:/tmp/cvs-serv13482
>
> Modified Files:
> aircraft.nas
> Log Message:
> respect /sim/startup/save-on-exit
Thanks !
Martin.
--
Unix _IS_ user friendly - it's just selective about who its fri
35 matches
Mail list logo
