James Turner wrote:
I'm plotting to add support for startup GUIs in FlightGear itself,
spurred on by recent issues with Mac GUI. My approach is to twiddle the
order of initialisation so that at a critical point during the
idle_state progression, the NewGUI subsystem is up, config options have
On 18 Apr 2006, at 08:56, Erik Hofman wrote:I'm plotting to add support for startup GUIs in FlightGear itself, spurred on by recent issues with Mac GUI. My approach is to twiddle the order of initialisation so that at a critical point during the idle_state progression, the NewGUI subsystem is up,
On 18 Apr 2006, at 10:07, Melchior FRANZ wrote:As you know, the reason for Nasal being the last of the subsystems is that it processes the files in $FG_ROOT/Nasal/ on initialization. And the idea was that these scripts should find all subsystems initialized, so that they can access some generated
* Melchior FRANZ -- Tuesday 18 April 2006 11:07:
Then Nasal files that *really* want to wait for a subsystem, could say
on_subsystem_init(environment, print_temperature);
Umm ... but what if it wants to wait for more than one subsystem. While
possible, that would quickly become disgusting.
On 18 Apr 2006, at 10:31, Melchior FRANZ wrote:Umm ... but what if it wants to wait for more than one subsystem. While possible, that would quickly become disgusting. Better real Nasal dependency resolution then. :-| I think adding more groups and keying off them is much easier - I don't have any
On 18 Apr 2006, at 11:36, Melchior FRANZ wrote:I think adding more groups and keying off them is much easier Sure. This wasn't meant as argument against your sublevel idea. (In my code I had added Nasal to the INIT group weeks ago, because this could have solved an exit problem that I had at
* Melchior FRANZ -- Tuesday 18 April 2006 12:49:
* James Turner -- Tuesday 18 April 2006 12:44:
I moved the 'end' part of NasalSys::init (running the
scripts) to postinit() to try and keep things working; I'm sure
that's not really the correct solution but it got things limping along.
Hi all,
I've just uploaded the first FGLive iso image release, namely 0.1
alpha.
I've tested it natively on my machine with a nvidia card, and it's
working pretty well.
It would be good if people with non-nvidia card can try it out. For
ati I've included 2 versions of fglrx
* Melchior FRANZ -- Tuesday 18 April 2006 12:53:
* Melchior FRANZ -- Tuesday 18 April 2006 12:49:
* James Turner -- Tuesday 18 April 2006 12:44:
I moved the 'end' part of NasalSys::init (running the
scripts) to postinit()
It probably breaks joystick drivers [...]
Umm, no. The end
David Luff wrote:
Steve Hosgood writes:
My only comment is just that 1937 maps will certainly be before the
National Grid was adopted, and will be based on the "old triangulation"
done between the late 1700's to mid 1800's. I don't know the details,
but it wasn't metric
On 18 Apr 2006, at 11:53, Melchior FRANZ wrote:Umm, no. The "end part"?! This should be OK then. But it gets more and more fragile because of such manually resolved dependencies. Agreed - hence this discussion. Otherwise we'll end up with postpostpostinit(), or as I like to call it, 'run level 4'
Didn't have a chance to look at this until last night. Anyway, hi Ralf,
cc'ing you to make sure you see it since this'll attach to an old thread
in flightgear-devel.
On Thu, 13 Apr 2006 15:27:11 +0200
Ralf Gerlich wrote:
Chris Metzler schrieb:
hgtchop didn't freak out for me; it was more of
From: James Turner
I'm plotting to add support for startup GUIs in FlightGear itself,
spurred on by recent issues with Mac GUI. My approach is to twiddle
the order of initialisation so that at a critical point during the
idle_state progression, the NewGUI subsystem is up, config
Hi,
Chris Metzler schrieb:
Well, I did mention this over there earlier, in the second paragraph of:
http://mail.flightgear.org/pipermail/terragear-devel/2006-March/001355.html
but however you saw it, I'm very glad, because . . .
I saw it in both lists, but the memory about me seeing the
Ralf Gerlich wrote:
Hi,
Chris Metzler schrieb:
Well, I did mention this over there earlier, in the second paragraph of:
http://mail.flightgear.org/pipermail/terragear-devel/2006-March/001355.html
but however you saw it, I'm very glad, because . . .
I saw it in both lists, but the memory
Jon Stockill schrieb:
*always* fully process your DEM before you start basing other stuff on
it. there's no need to run arrayfit - but it will get rid of a lot of
redundant data. It's worth the time spent processing it. Then *back up
the result* you won't need to go back to that step until
The good news:
SimGear and FlightGear work with gcc's precompiled headers
This is good news; however, I must say that I have working code
(albeit very heavily template-laden, much more than FG), that
doesn't work with the gcc's precompiled headers, even with the gcc4.x;
so I wouldn't trust
Clarification:
Your change might be incompatible with such platforms.
...as long as it comes unaugmented by a common header
imposing a single order on the headers included to be dumped out
into the pre-compiled header database
---
This SF.Net
Curtis L. Olson wrote:
The son of one of the Tuskegee airman would love to have us do a repaint
of our P-51 in the classic Tuskegee scheme with the distinctive red tail.
I don't know the best place to get official information on the marking
scheme, but if you do a google image search for
Feel free to comment.
Cool. It would be nice to have an ability to associate multiple callsigns
with the same username (so that one can use various callsigns for various
planes/missions).
Vassilii
---
This SF.Net email is sponsored by xPML,
* Frederic Bouvier -- Tuesday 18 April 2006 23:13:
What about applying the simple patch attached. It doesn't cure the
double entries problem, but it ensures that no valid memory is returned
to the system before all references on it are released.
Almost everything is better than crashes, but in
John Wojnaroski wrote:
Curtis L. Olson wrote:
John Wojnaroski wrote:
There will be some slight hesitations when new tiles are loaded.
It's possible that a large dt could cause you to overshoot your
target. If you factor dt into your control algorithm (if it's not
already) that might
22 matches
Mail list logo
