There's a TODO message in multiplaymgr.cxx that says:
// A static map of protocol property id values to property paths,
// This should be extendable dynamically for every specific aircraft ...
This static list grows and grows and that's becoming a problem. I
hardly ever take part in MP,
* Maik Justus -- Wednesday 03 October 2007:
The actual MP code does not send all properties of the static list. It
only sends those properties, which are existing at initializing of the
MP-code. Thats why you need to define some properties within the
-set.xml file [...]
Ahh, thanks for the
Today I added a function for retrieval of airport/runway information.
Usage:
var apt = airportinfo(KHAF); # get info about KHAF
var apt = airportinfo(lat, lon); # get info about apt closest to lat/lon
var apt = airportinfo(); # get info about apt closest to aircraft
The command
Here's a first stab at a glide slope tunnel visualization utility.
It's a rather short Nasal script which uses the new airportinfo()
function. It requires a *very* up-to-date FlightGear. To try it out
just put it into ~/.fgfs/Nasal/ or $FG_ROOT/Nasal/.
http://members.aon.at/mfranz/gstunnel.nas
* Bill Galbraith -- Tuesday 02 October 2007:
Can you send a screen shot or two?
http://members.aon.at/mfranz/gstunnel.png [159.7 kB]
Needed to use png, as jpg made the lines look really ugly. :-)
m.
-
This SF.net
* Melchior FRANZ -- Tuesday 02 October 2007:
http://members.aon.at/mfranz/gstunnel.png [159.7 kB]
Made a better smaller one: [45 kB]
The whole thing is quite simple and flexible. Most of what's
needed is already there in one of the Nasal library scripts
in $FG_ROOT/Nasal/ and available
* Durk Talsma -- Monday 01 October 2007:
I think we had some reports on stutter showing up on fgfs devel
late last year. Probably around December. I'd say that around
October last year everything was still reasonably smooth.
I wrote this on 2006/2/25 to fgfs-devel with subject
Re: AI problems
* Durk Talsma -- Sunday 30 September 2007:
Thirdly, there is a relation between execution time and listeners,
Err ... Nasal listeners trigger Nasal code when the listened-to property
is written to. Executed code costs cpu cycles. Anyone surprised?
If listeners are used badly and trigger bad
* Melchior FRANZ -- Sunday 30 September 2007:
If listeners are used badly and trigger bad code, then this will, of
course, hurt the framerate. But that's not because listeners are bad.
I have to add, though, that the listener code in hsi.nas doesn't look
particularly slow, so it shouldn't cause
* Durk Talsma -- Sunday 30 September 2007:
Although most people will have a global idea as to what listeners
are, I don't think that *that* many people are aware of the fact
that the actual setValue function is the very same code that calls
these Nasal functions.
Ah, ok. Indeed, things can
* Tim Moore -- Saturday 29 September 2007:
Can you try this patch?
Works!
m.
BTW: this can be tested with something like this:
var lat = props.globals.getNode(/position/latitude-deg);
var lon = props.globals.getNode(/position/longitude-deg);
var check = func {
* Nick Othieno -- Saturday 29 September 2007:
ssgaSky.h:107: error: extra qualification 'ssgaCelestialBodyList::' on
member 'ssgaCelestialBodyList'
Solution 1: use 1.8.5pre, where it's fixed (preferred)
Solution 2:
--- ssgaSky.h (revision 1798)
+++ ssgaSky.h (working copy)
@@ -104,7
* wim van hoydonck -- Thursday 27 September 2007:
The attached patch adds support for the Saitek Cyborg evo Wireless
joystick to Flightgear by adding its name to the Cyborg-Evo.xml file.
Committed. Thanks.
m.
-
This
* Durk Talsma -- 9/25/2007 9:20 PM:
What I don't understand yet is that I'm getting timing alerts
in subsystems named instrument8, controller, system1, and more, which I
can't trace back anywhere in the source code. My question: Are these
subsystems dynamically created using a nasal script,
* Melchior FRANZ -- 9/26/2007 8:11 AM:
* Durk Talsma -- 9/25/2007 9:20 PM:
Are these subsystems dynamically created using a nasal script,
or an xml configuration file?
Neither. They are created by c++ in other subsystems,
Correction: not from Nasal, but the instrumentation subsystem
* Heiko Schulz -- 9/22/2007 6:53 PM:
I think that there are maybe some more causes than
only the setlistener.
While I still don't think that listeners are even one of the
causes, I agree that there could be more sources. Some bad
timing.
And I'm sure v0.9.10 had it too.
So am I. Actually,
Hi,
* gh.robin -- 9/16/2007 2:48 AM:
I get from some French developer, destructive pressure over
destructive pressure, [...]
I don't know exactly what's going on here, but I guess it's still
about a modified version of cessna-fire.osg from the OSG demo data
package? Last time I checked I
* Jon S. Berndt -- 9/7/2007 1:33 AM:
[ground material aware gear handling in JSBSim]
Well, if I was the one doing the ridiculing, I apologize.
No need to, you weren't, IIRC. :-)
But the ridiculing became known to the IRC participants, and this
caused very upset (and slightliy exaggerated :-)
* gh.robin -- 9/6/2007 12:05 AM:
We can with an external property scenery material type to process
correctly the aircraft reactions according to the type.
And which material should this report? The one under the left
wing tip, or the one 150 m behind the tail, or what?! FlightGear
has no
* gh.robin -- 9/5/2007 4:15 PM:
groundcache.cxx seems to be able to give the material information
[...]
With a specific property we could have it fully opened.
Isn't the property tree, but might be useful nevertheless:
There's a Nasal function geodinfo() that returns material and
other
* Melchior FRANZ -- 9/5/2007 5:15 PM:
If you really need it in the tree (e.g. for XML animations), then [...]
Oh, and ai submodel impacts report the material in the property tree
already, along with other impact data.
m
* gh.robin -- 9/5/2007 5:43 PM:
i find nothing regarding impacts in the submodel property tree.
See $FG_ROOT/Docs/README.submodels and the seahawk for an example.
If impacts are enabled in the submodel XML config file (impact),
then every impact generates a dir entry in /ai/models/ with all
the
* gh.robin -- 9/5/2007 6:16 PM:
unfortunately that is only available with submodel,
which does not answer the request regarding the model itself.
Yes. But it's information that needs to be available per gear,
not for /position/{latitude,longitude}-deg. And YASim provides
this information,
* gh.robin -- 9/5/2007 6:37 PM:
* On mer 5 septembre 2007, Melchior FRANZ wrote:
But it's information that needs to be available per gear,
[...] it has to be added to the JSBSim/fgfs interface.
to me, It is not necessary to include it within JSBSim
But that's IMHO the only way that makes
* SydSandy -- 9/3/2007 3:11 PM:
is there a way to format a double and output that to a string
property with writing the double to a property first
without? - sprintf()
m.
-
This SF.net email is sponsored by: Splunk Inc.
* Vivian Meazza -- 9/3/2007 10:22 AM:
That would be 90% of the 10% who aren't Windows users then? Don't forget
that by far the majority of our users out there are on Windows, as opposed
to the developers for whom the ratio is probably reversed.
While I agree with your demand to keep fgfs
* Ralf Gerlich -- 9/3/2007 6:41 PM:
Melchior FRANZ wrote:
While I agree with your demand to keep fgfs cross-platform, which is
one of its central properties, I don't buy the 90% of the fgfs users
are on Windows myth.
Independent of that it's probably better to have something working
* Harald JOHNSEN -- 9/2/2007 10:35 AM:
The old implementation of the Harris code in fg was using hard coded
cloud shape, hard coded cloud relative position between clouds, hard
coded group of cloud around ksfo. The next implementation could [...]
Wasn't that some kind of improvement ?
Yes,
* Detlef Faber -- 8/31/2007 4:50 PM:
Just great! I've reworked the bf109 and it just works!
That's funny. Haven't I sent you a patch for the bf109 to use the
new livery dialog *months* ago? You said you'd commit it later ...
m.
* Melchior FRANZ -- 8/31/2007 9:59 AM:
Listeners are not involved, unless you have very badly written ones on
your
harddisk (only). When you brought that up last time I added some logging
capabilities for listeners and disproved this claim.
See this mail for how to log listener calls
This thread started as bug report about a recent problem with dynamic
view, but
people used it as opportunity to throw in their favorite bugs, although
those are
apparently unrelated. Let's keep things separated:
Bug #1: stutters and pauses with 1-2 sec lenght when dynamic view is
enabled
First of all: I apologize for the horribly formatted message. That was
caused by a badly configured Mozilla Thunderbird on this machine (which
isn't mine). Should be fixed now. And it was hard work! :-)
* leee -- 8/31/2007 4:48 PM:
It wasn't my intention to criticise listeners in any way - I
* Detlef Faber -- 8/25/2007 11:11 AM:
does anybody object against putting the jeep into CVS?
Nope, just on the contrary: I would have asked you to commit it.
I'm not aware of any policy. After all it's just an aircraft with rather
poor flying behavior ... :-)
m.
It's now possible to put Nasal files into $FG_HOME/Nasal/, that
is: ~/.fgfs/Nasal/ on Unix, and %APPDATA%\flightgear.org\Nasal\
on MS Windows. This has the advantage that:
- one doesn't have to mix local extensions with standard files
- one is less likely to lose such local additions when
* SydSandy -- Sunday 05 August 2007:
Ive added ascii properties to the autopilot route-manager waypoints ,
the same as the Instrumentation/nav id , because adding 2d text to the
Primus 1000 PFD and MFD makes it difficult to
re-use in other aircraft , and the 2d text is harder to read and
* SydSandy -- Sunday 05 August 2007:
Its simply a copy of a routine in navradio.cxx ,
Eeew ... indeed. And because our cvs history got disrupted for no
good reason and there are no meaningful comments, it can't even be
tracked back. But it's very old code, and nobody seems to use those
* SydSandy -- Sunday 05 August 2007:
On Sun, 5 Aug 2007 11:30:09 +0200 Melchior FRANZ [EMAIL PROTECTED] wrote:
... but only with wanting to use the ascii code as offset in an
alphabet stripe on a texture. In that case (and if Nasal can't be
used) we should think about a different way
* SydSandy -- Sunday 05 August 2007:
Melchior FRANZ [EMAIL PROTECTED] wrote:
One could just add a parameter to the animations where it's needed [...]
that defines that not n.getDoubleValue() should be used to read the value,
but int(n.getStringValue()[pos]), where pos is read from string
* Stuart Buchanan -- Thursday 26 July 2007:
It interpolates METAR changes over time as follows:
Committed, thanks. This was sorely missing, but I'm afraid
we'll get complaints because the real-life-weather doesn't
work any more. (No more obvious weather changes shaking the
aircraft. ;-)
m.
* Markus Zojer -- Wednesday 01 August 2007:
That should be all, hopefully everything works now.
No, doesn't:
Nasal runtime error: setprop() value is not string or number
at $FG_ROOT/Aircraft/B-1B/Nasal/b1b.nas, line 359
That's because init_b1b() is called with settimer(..., 0) and not
* Markus Zojer -- Wednesday 01 August 2007:
Melchior FRANZ wrote:
That's because init_b1b() is called with settimer(..., 0) and not
with setlistener(/sim/signals/fdm-initialized, ...);
Thats not beautiful, I agree but worked for me ..
It's one of the bugs that depend on installation
* Melchior FRANZ -- Wednesday 01 August 2007:
This looks like a bug, too: setprop(sim/multiplay/chat_display, 1);
(although I haven't seen any effect).
OK, I found out. The property got renamed to /sim/multiplay/chat-display
and is now saved to autosave.xml. So you can leave that setprop
* Maik Justus -- Tuesday 31 July 2007:
(I have used blurred sounds of several tools (drill, mixer, ...))
Heh ... sounds quite convincing. :-)
I don't think I would like to be pilot in a real v22 (seeing the huge
rotors directed at me through the side window would make me a bit
nervous :-),
Those using kttsd (KDE's Text To Speech Daemon), for example, to
let the konversation IRC client speak received messages[1], may
want to avoid running the festival server with all its voices twice.
The attached perl program festival-server pretends to be
festival --server and hands all messages
* Jon S. Berndt -- Saturday 28 July 2007:
It was asked in the German fgfs forum[1] if it's possible to log
internal data to an XML file. Sure is! :-)
There are probably several ways within Flightgear to do this. If one is
interested in flight dynamics parameters you can also do this in
* Jon S. Berndt -- Saturday 28 July 2007:
[...] or to output to socket
To be fair: this is also something that the one from the German forum
asked for, and what the Nasal version doesn't do. Well, except if
don't mind abusing the system:
$ fgfs \
--prop:sim/sound/voices/enabled=1 \
* Melchior FRANZ -- Saturday 28 July 2007:
It was asked in the German fgfs forum[1] if it's possible
to log internal data to an XML file. Sure is! :-)
And now it's also possible to do via regular generic protocol.
Writing XML is a trivial thing (unlike readingparsing), but the
generic protocol
It was asked in the German fgfs forum[1] if it's possible
to log internal data to an XML file. Sure is! :-)
The attached file put into $FG_ROOT/Nasal/ starts logging
to /tmp/data.xml as soon as the FDM is up (one data set per
second) and stops when fgfs is closed. Because the 1 second
interval
* Melchior FRANZ -- Friday 27 July 2007:
Then change externals address from com to org (shouldn't really be
necessary, but maybe they forgot switching in the repository?).
$ svn propedit svn:externals .
[ editor opens ... change both com to org ]
That's now fixed in SVN, so you can drop
OpenSceneGraph CVS was on server openscenegraph.org. For the switch
to SVN, address openscenegraph.com was temporarily used, with the
intention to switch back to *.org at a later time. This has now
happened. Fortunately, it's quite easy to switch a local checkout
to the new address.
$ cd
* Stuart Buchanan -- Thursday 26 July 2007:
http://www.nanjika.co.uk/flightgear/Environment.diff
[...]
If someone could review the code and check it in to CVS if it passes
muster, that would be appreciated.
I've applied that locally and will test and commit at the weekend
if it works. (I'll
* Hans Fugal -- Thursday 26 July 2007:
So we likely are looking at a memory corruption bug in OSG
Yes. That looks very much like an OSG bug. And valgrind agrees.
The textures are perfectly valid. BTW: according to my checker we
don't have a single corrupted SGI image file in CVS.
m.
* Hans Ulrich Niedermann -- Thursday 26 July 2007:
Hans Ulrich Niedermann wrote:
Rip out SDL from current CVS? IMHO, yes.
Patch is here: http://flightgear.lauft.net/FG-remove-SDL.patch
The correct order is:
- fix repeatable keys and mouse wrapping/warping in osgviewer
- make sure osgviewer
* Melchior FRANZ -- Thursday 26 July 2007:
Yes. That looks very much like an OSG bug. And valgrind agrees.
I have to take this back. The code is rather ugly -- it reads more
data than are available, and valgrind complains about that. But after
that the line decoder breaks correctly. I don't see
* Tim Moore -- Thursday 26 July 2007:
I'm still quite interested in your GSA change with the cleanup you mentioned
of moving plib init stuff into the GSA classes and will commit it unless other
developers object.
I object to the 23 files changing patch that puts all interfaces into
every fgfs
* Hans Ulrich Niedermann -- Wednesday 25 July 2007:
23 files changed, 698 insertions(+), 184 deletions(-)
Umm ... and this huge change only to stuff GLUT, SDL, *and*
OSGVIEWER support into the same binary, as a minor development
helper for two months or three, until we can rip out GLUT and
SDL
* Hans Ulrich Niedermann -- Sunday 22 July 2007:
As the whole thing is still in development, it makes sense for
developers to have more than just one of the three, so that one can
compare their behaviours.
And how many developers actually do it? My guess: one. That would
be you. But you have
* AnMaster -- Tuesday 24 July 2007:
Melchior FRANZ wrote:
[...] In the PLIB branch
we should rather make SDL default, as freeglut is notoriously broken
(repeatable keys; reportedly slower FPS(?)). And in the OSG branch [...]
We shouldn't: fg/SDL breaks on Swedish keyboards at least.
You
* Norman Vine -- Tuesday 24 July 2007:
Melchior FRANZ writes:
* Hans Ulrich Niedermann -- Sunday 22 July 2007:
As the whole thing is still in development, it makes sense for
developers to have more than just one of the three, so that one can
compare their behaviours.
And how many
* Hans Fugal -- Tuesday 24 July 2007:
He didn't have an argument. He had a solution
Yeah, but what annoys me is that it's a solution that is in fact about
turning fgfs into shared libs, but disguised as a solution for (allegedly)
responsible developers. The former is a rather big change, the
I've downloaded bo105 photos from here quite a while ago -- some
of them are of very good quality and in high-resolution:
http://www.primeportal.net/the_airstrip.htm
m.
-
This SF.net email is sponsored by: Splunk Inc.
* Melchior FRANZ -- Saturday 21 July 2007:
(I only changed text files with MSDOS line terminators to Unix
style according to fgfs rules. :-)
I also removed the userarchive flags on the hobbs and yoke properties,
and let those properties be written to the c150's own aircraft config
instead. I
* Harald JOHNSEN -- Sunday 22 July 2007:
I'll make the change to overide the other function too.
Ahh, I hadn't thought of JSBSim using hard-coded property paths.
Yes, looks like redefining the other function is the only solution
then. Will fix lots of joysticks *and* the key binding (m/M keys).
* Harald JOHNSEN -- Saturday 21 July 2007:
http://sites.estvideo.net/tipunch/flightgear/c150.zip (3 Mb)
Committed, thanks. I was missing the c150.
(I only changed text files with MSDOS line terminators to Unix
style according to fgfs rules. :-)
m.
* Bill Galbraith -- Saturday 21 July 2007:
If you are following a discussion, it's nice to see the reply at the
top, so that you don't have to scroll through a lot of stuff, just to
see okay, I'll try that.
Top posting is always annoying and wrong. Of course, it's bad to
have 100 quoted lines
* Jon S. Berndt -- Saturday 21 July 2007:
is HTML to be avoided?
I can't stand HTML messages. HTML messages are for web pages, for
blinking stuff and pony pictures, but meaningful text doesn't usually
need HTML. It's just hard to keep people from using it. (Maybe with
a nasty filter on the list
* Anders Gidenstam -- Tuesday 17 July 2007:
- Change controls.nas so throttle input to only affect the selected engines.
This has been committed. Thanks. I've only made some minor changes,
that have made your code actually *less* consistent with the existing
controls.nas code. This is because I
* JOSHUA WILSON -- Monday 16 July 2007:
/home/innis/Flightgear/data/Aircraft/787/Models/nd.ac
Reading image Segmentation fault (core dumped)
Can't reproduce that. Both nd.ac and nd.rgb seem to be OK (no
corruption or syntax errors).
You might try removing the 787 model from your computer
* JOSHUA WILSON -- Monday 16 July 2007:
[attribution line was removed: Melchior FRANZ]
But what I noticed is that several (all?) of the textures are
uncompressed. This wastes 12.6 MB disk space
Sorry about the large files.
Large files are not the problem. But unnecessarily large files
* gh.robin -- Friday 13 July 2007:
Here is a new version of SR71-BlackBird.
Committed, thanks. (I picked up the newer version that you posted
on the IRC channel.)
m.
-
This SF.net email is sponsored by DB2 Express
Download
* Melchior FRANZ -- Sunday 15 July 2007:
But there are problems with the 787:
Some more:
Nasal runtime error: nil used in numeric context
at $FG_ROOT/Aircraft/787/Nasal/system.nas, line 193
Nasal runtime error: setprop() value is not string or number
at $FG_ROOT/Aircraft/787/Nasal
* Stefan Seifert -- Sunday 15 July 2007:
The largest open source project with thousands of developers, namely the
Linux kernel itself does not have the slightest idea of a road map, even
though most of the developers are in fact paid to work on it. And it
works pretty well.
Exactly.
I'm
* leee -- Saturday 14 July 2007:
Perhaps FG has reached the point where it positively needs some
sort of oversight management and planning, as seems to happen
with many, if not most, large-scale Open-source projects
e.g. Apache, Wine etc.
I think that projects where this works always have a
* Anders Gidenstam -- Friday 13 July 2007:
I think it might also be nice to use a nasal wrapper for the PTT key
binding (like most things in controls.nas), that way a user could more
easily add more bindings for PTT (e.g. a joystick button).
Yes, of course. I plan a two-stage wrapper. One
* AnMaster -- Friday 13 July 2007:
I think it makes sense to change from space, but I'm not sure about to s.
After all that key is quite easy to hit by mistake (some other such are t/T
and r, all those should be moved some less dangerous place as I don't think
they are used a lot either).
And
* Heiko Schulz -- Friday 13 July 2007:
O.k. - but then I think (suggestion) it should be
seperated into branches of combat, sailing, driving,
etc...
FDMs are already separated. You have to restart fgfs to change
the mode. (Unfortunately!)
I can really remember, that one of you said, that
* Heiko Schulz -- Friday 13 July 2007:
Of course it is open for all and everyone can do what
he want. But with this way we loose a lot of abilities
to develop.
Which abilities do or did we lose exactly? And how?
It looks very chaotic for me - and that's
one point which maybe scares other
* Csaba Halász -- Tuesday 10 July 2007:
I have split my modifications into smaller changes so that they can
be reviewed and applied individually, but nobody cared [...]
Nobody cared? You presented it on the list, but never asked for
it being committed. Or have I missed something?! What you did
* Markus Zojer -- Tuesday 10 July 2007:
http://homepage.univie.ac.at/markus.zojer/fgfs/B-1B.tar.gz
start with --aircraft=B-1B
Thanks, committed. I changed the line endings in one file from
DOS to UNIX, made absolute paths in the animation file relative,
and I had to crop the thumbnail.
* Anders Gidenstam -- Saturday 07 July 2007:
In my work on LZ-129 Hindenburg I discovered that I need to be able
to quickly control the engines individually or in (sub)groups
I've thought in the past that the throttle should really respect
the selected engines.
1. throttleMouse(),
* Maik Justus -- Tuesday 03 July 2007:
here is the patch for the directional sound and correct Doppler sound
(and stereo sound) for the plib branch.
Committed. Well, actually I have missed this patch and first committed
the one from Sun, 01 Jul 2007, but then committed the rest. I hope I
Hi,
I didn't intend to take part in more threads with you that could
(and most likely would) turn out to be yet another flame war. The
following is really meant to be the opposite, but I assume that
it will fail poorly.
* John Denker -- Friday 06 July 2007:
I'm sure some people will take this
* John Denker -- Wednesday 04 July 2007:
Bottom line: Does anybody have any suggestions and/or
questions about this work?
Well, there are still two objections concerning the submissions:
- the name gremlins.nas. But this could certainly be changed by
whoever commits this. I suggested
* John Denker -- Wednesday 04 July 2007:
Well, there are still two objections concerning the submissions:
[- fixed size and positions of dialogs]
- the name gremlins.nas. But this could certainly be changed by
whoever commits this. I suggested failure.nas. The function
name
* leee -- Wednesday 04 July 2007:
Is it really worth making an issue over two and three character
local variable names?
My comments weren't made as a random list subscriber, but as
someone who was about to commit the stuff, and would have liked
some things changed first. And yes, that also
* Stuart Buchanan -- Tuesday 03 July 2007:
The included XML files replace those in the gui/dialogs directory, while
gremlins.nas should be put in the Nasal directory.
gremlins.nas? Please not funny names in $FG_ROOT/Nasal/. These
are code files, and so far all of them were called after their
* John Denker -- Tuesday 03 July 2007:
This implements a popup to show the position of the flight controls
and trim.
[...]
http://www.av8n.com/fly/fgfs/flight-control.diff
Certainly useful for many people. I think a third digit after the
comma would be useful for axes, as two are barely
* John Denker -- Wednesday 04 July 2007:
On 07/03/2007 06:09 PM, Melchior FRANZ wrote:
What I don't really understand is why local variables need to be ii and
nnn. What's wrong with just i and n, like everyone else uses?
Skilled programmers double the i and triple the n so
Oh, sorry. Forgot this one ...
* John Denker -- Wednesday 04 July 2007:
I can see making another mode, to serve another purpose, such
as debugging joysticks, and /four/ digits would be worthwhile
in that case. It would be simple to put a mode-change button
on the existing popup.
I'd assume
* Melchior FRANZ -- Monday 02 July 2007:
Sure, a property that turns every serious exception into a segfault
couldn't hurt. A segfault, not an abort()!
Uh, I know: An abort() *makes* a coredump. I meant an exit(). :-)
m
* Melchior FRANZ -- Monday 02 July 2007:
I would definitely not ignore a message from the traffic manager:
Traffic Manager problem in src/Traffic/TrafficMgr.cxx, line 341:
routing problem in EHAM data -- no endpoint found
OK, here's the first addition: I've just added a macro SG_ORIGIN
I appreciate your work on the Traffic Manager, but ...
* Durk Talsma -- Sunday 01 July 2007:
The message is related to a routing problem in the AI system,
which actually causes a controlled exit from FlightGear.
Please remove the controlled exit. There's no reason why a
user flying along
* Melchior FRANZ -- Friday 29 June 2007:
Here's a new, adapted ai.nas version:
http://members.aon.at/mfranz/ai.nas [1.7 kB]
If you try this out with CVS/HEAD and it doesn't work, then just
download it again from here, as I'll upload new versions if necessary.
I just did that, as a commit
* Melchior FRANZ -- Friday 29 June 2007:
http://members.aon.at/mfranz/ai.nas [1.7 kB]
It's a bit faster, too, although 8.7 seconds for EHAM/parking.xml
is still a lot (was 12.8 before).
And that comes from bad Nasal code, not from the c(++) expat/EasyXML
parser code, which is very fast
* Melchior FRANZ -- Thursday 28 June 2007:
And what is it good for? For *nothing*. Well, for showing off
some recent Nasal additions: [...] the xml parser.
... which I just removed. We have an interface to the built-in
parser now. Here's a new, adapted ai.nas version:
http://members.aon.at
Here's a small Nasal file to play with (attached). If you put
it into $FG_ROOT/Nasal, start fgfs with the ufo and press the
g-key, then you get a file-select dialog where you can select
a parking.xml file. When you click the Load button, then an
object is placed at every TaxiNode of the chosen
* Melchior FRANZ -- Thursday 28 June 2007:
Here's a small Nasal file to play with (attached).
Whoops ... please change the setlistener call to a _setlistener
call (with leading underscore). Otherwise it may not run on some
systems.
m
* Melchior FRANZ -- Tuesday 26 June 2007:
There's no release imminent for fg/osg, and we have time to clear
matters and don't need to rush in a workaround for a (potentially)
long fixed bug.
I guess things are clear now. Read through this thread:
http://opensource.creative.com/pipermail
* Erik Hofman -- Tuesday 26 June 2007:
Since it seems to be a Windows problem it's not a matter of depending on
a svn build or not.
Im must say, though, that my reluctance to commit that was based
on the assumption that Doppler is really only functional in fg/osg,
but not fg/plib. There's no
* Melchior FRANZ -- Friday 22 June 2007:
if nobody does that until tomorrow 2007/06/23 20:00 GMT, then I will:
(a) apply those radar patches to sg and fg for osg and plib
(b) comment out the delete rt in src/Instrumentation/od_gauge.cx:89
Done. These patches give quite good results
801 - 900 of 1620 matches
Mail list logo
