Hi,
I finally had time to update the Wiki with detailed information on the
EGPWS configuration. I think the module has been there for quite a
while - but the manual was lacking a bit of detail. Also, I fixed a
few stability issues and added two more configuration options.
Could s.o. please have
Ahh, classic moment... So here's the attachment...
On Sun, Jul 25, 2010 at 12:42 AM, ThorstenB wrote:
Hi,
I finally had time to update the Wiki with detailed information on the
EGPWS configuration. I think the module has been there for quite a
while - but the manual was lacking a bit
Hi,
maybe I can raise some more attention to a specific bug, which keeps
me from using FG properly. I have also heard a number of other people
complaining. If I could vote, I'd like to vote for this issue to be
the currently most annoying FlightGear bug:
Scenery tiles keep disappearing (when
On Sat, 18 Sep 2010 16:57:11 +0200, Arnt wrote in message
20100918165711.24d2d...@a45.fmb.no:
..can happen in RL too, this is when you swear a wee bit, pick up
your flight plan and pick our best alternate destination from it
just like the RL guys does.
Knock knock, Neo. The effect here is not
On Saturday, September 18, 2010 18:32 Durk Talsma wrote:
Given, my observation that cycling through all the viewpoints, will restore
the visibility of tiles that have gone lost, and flag tiles that were visible
during the previous view cycle invisible, makes me suspect that something in
the
Hi,
good news - I've done more debugging in the tile cache module and
think I already found something...
I'm seeing two issues with the tile cache, sometimes causing active
scenery to be kicked when the cache is full - and this results in the
missing patches. I'm also seeing cases where all
Hi Tim, Curt, et al,
I've prepared a patch and did a number of test flights tonight - and
had no more scenery issues. I'll still do a bit more testing, but
maybe someone else seeing these problems regularly could already
check, if this fixed their problems, too. The patch is attached to the
bug
Hi,
there is a forum topic discussing compiler optimization to improve
frame rate ( http://www.flightgear.org/forums/viewtopic.php?f=45p=96830
).
I have also tried this (and successfully improved mine... :-) ).
However, I also compiled with -Wall and this shows several issues
with the FlightGear
On 2010-09-27, at 17:25, James Turner wrote:
The SSE math flags are a no-brainer where supported - the
-march-native and -sse flags are all Apple defaults in Xcode.
BTW, as far as I remember the -sse and -sse2 are on by default for GCC
on AMD64 (alias x86_64).
It would be good if someone who
Hi,
I fixed the strict-aliasing issues reported by GCC 4.4.1. Affects the
generic.cxx and multiplaymgr.cxx modules.
I created a merge request (let me know if you preferred patches):
http://gitorious.org/fg/flightgear/merge_requests/7
cheers,
Thorsten
Hi,
On 2010-09-28, at 01:11, Csaba Halász wrote:
I fixed the strict-aliasing issues reported by GCC 4.4.1. Affects the
generic.cxx and multiplaymgr.cxx modules.
Unfortunately the trick with the union in multiplaymgr.cxx is not
standard C, as far as I know.
well, unions are ANSI C. I guess
From: Markus Kirchner 2010-10-25 16:40
Hello,
I did a few improvements to my 777-200 on autopilot functions (FlightGear
version 2.0.0). So pretty much of all function worked well e.g. LNAV on route
mgr and on NAV-radials, HDG SEL, TRK SEL etc.
For these function I used the properties,
From: thorsten.r...@jy... - 2010-11-12 10:13
I still have no real understanding why this is so, or why loading a large
number of *identical* models into the scenery should take a long time (I
would think that one can make use of the fact that there are really
multiple copies of the same model
From: James Turner zakal...@ma... - 2010-11-12 13:37
Just to re-iterate - the best defence is a good offence. Stop worrying about
FPS, and make FG
better (by contributing), or promoting it better. It's essentially a
marketing scam, not a competing
product. (The current flightgear.org
Unfortunately this means METAR is broken (probably permanently) for
all previous FG versions now...
As a follow-up to the METAR issue: there actually is a workaround for
FG 1.9.x and 2.0 - by using a proxy server. The requests sent by FG to
a configured proxy server are fine. And the actual
Another heads up: I've pushed an update for scenery tile management.
It's a follow-up to the recent patch fixing random empty scenery
patches, providing some more improvements:
* Priorities for tile loading. Tiles are now loaded in innermost to
outermost order. Means a better optical effect when
From: Roland Haeder r.hae...@gmx.de
I have 15 FPS here with a GeForce 9500 GT (MSI) and a quad-core. How
can I change that draw distance? It is really far. :(
The visibility shouldn't have changed with this update - except that
the visibility selected at start-up is immediately effective now.
From: fiers...@zo... - 2010-11-20 10:33
I have done two tests, directly after eachother. Same conditions, same METAR.
One thing to note here is that, prior to yesterday's update, the size
of the scenery area loaded/rendered at start-up did _not_ depend on
the visibility (weather/METAR), neither
On Sat, Nov 20, 2010 at 10:41 PM, Heiko Schulz aeitsch...@yahoo.de wrote:
But needs more time to get a stable and usuable fps...about 30seconds here
with latest GIT from today.
Right, the splash screen is down early now, while FG is still busy
loading more distant scenery areas. Loading in the
On Sat, Nov 20, 2010 at 11:48 PM, Heiko Schulz wrote:
Not yet completly tested, but I notice the first 30 seconds of startup fps of
1-2.
Imagine the same fps when loading new tiles would make FGFS pretty unusuable
for me
If you refer to the fps _before_ the splash screen is dropped,
On Sun, Nov 21, 2010 at 11:35 AM, Arnt Karlsen wrote:
..maybe either hide the fps display or use it to tell
what's going on until the splash screen events are all
done?
Right. Accidentally that's exactly what I looked into after
yesterday's discussion.
On Sun, Nov 21, 2010 at 12:37 PM, Heiko Schulz wrote:
The problem isn't while the splash screen- it occurs for several seconds
after splash screen dissapeared- this will be the problem.
Yes, that is understood. Still, at least showing 1-2fps in the splash
screen phase can be avoided, since
On Wed, Nov 24, 2010 at 5:35 PM, Donn Washburn wrote:
It also seems that the most recent fgdata (todays version) gives this error
d...@m1l-susehs:~ fgfs aircraft=737-300
Processing command line arguments
Fatal error: Failed to open file
at aircraft=737-300
(received from SimGear XML
On Tue, Nov 30, 2010 at 2:14 PM, Heiko Schulz wrote:
Thorsten B has done a huge amount of work on the GPWS in
the past few months, my impression is that with the latest
Git code, it's working better than at any point in its
history - with the caveat, assuming you have configured it
On Tue, Nov 30, 2010 at 7:54 PM, Heiko Schulz wrote:
I had a look into, even ported the related subsystems over to the 733, but no
success.
Scott (working on the A380) noticed the same with the wiki-tutorial and the
GPWS. Interesting to know and maybe a hint: A380 and 733 are both JSBsim.
On Tue, Nov 30, 2010 at 10:55 PM, Heiko Schulz wrote:
As this is a pretty accurate emulation of the real thing (or maybe it is even
the real thing.. ;-)), how it gets its datas in real life? What is the source
in reallife?
The RL device may be configured to a number of radio altimeters -
On Wed, Dec 8, 2010 at 11:14 PM, Roland Haeder wrote:
I use the following call to start FGFS:
--
fgfs...
...
--aircraft=aircrane --enable-fpe
Thanks, that actually always reproduces it.
And the temperature at EDDL can now really be at 0 deg. Celsius because
of
On Thu, Dec 9, 2010 at 1:12 AM, Heiko Schulz wrote:
Not really, as I or helijah is not the author of the aircrane-fdm.
Oh sorry, didn't want to credit the wrong person! :) (maybe a
copypaste problem since you're credited in the readme).
But Maik Justus, the author of it, told me once ( and it
On 11.12.2010 09:16, Durk Talsma wrote:
Firstly, what is the next version number going to be. My initial
thought would be 2.1.0, but it also makes sense to call if 2.2.0
(thanks for the suggestion, James), so that we can reserve 2.1.0. for
bugfixes on the current version, or at least move toward
On Mon, Dec 20, 2010 at 9:12 AM, Roland Haeder wrote:
I got another FPE with GIT version while in-flight with the A380 (recent
updates of fgdata). I flew with auto-pilot turned on from EDDL to EHAM
and suddenly the FPE happens:
I had a look into some of these FPEs. However, there's tons of
The F14 disables the first menu item from the 5th menu
ext_stores.nas = setprop(sim/menubar/default/menu[5]/item[0]/enabled, 0);
Not sure which menu item originally was at this location.
Quite bad. Harded coded hacks like this just always break... ;)
cheers,
Thorsten
On Thu, Dec 30, 2010
ordering?
cheers,
Thorsten
On Thu, Dec 30, 2010 at 6:37 PM, ThorstenB bre...@gmail.com wrote:
The F14 disables the first menu item from the 5th menu
ext_stores.nas = setprop(sim/menubar/default/menu[5]/item[0]/enabled, 0);
Not sure which menu item originally was at this location.
Quite
On Thu, Dec 30, 2010 at 10:47 PM, Citronnier - Alexis Bory wrote:
Yes, it was intended to disable the stock Fuel and Payload menu. I'll
adapt the code to follow the new ordering. It should be in git very soon.
On Thu, Dec 30, 2010 at 10:52 PM, Scott Hamilton wrote:
Actually this might not
On Fri, Jan 7, 2011 at 6:58 PM, Curtis Olson wrote:
I make a small test edit to a file (src/GUI/MapWidget.cxx).
I run git checkout next to return to the pristine unchanged branch that
tracks the head on gitorious --- but here is the output:
$ git checkout next
M src/GUI/MapWidget.cxx
On Fri, Jan 7, 2011 at 7:48 PM, Curtis Olson wrote:
So what happens if I'm messing around with my WildCrazyIdea-I-WantToTry
branch over lunch, and suddenly I get a phone call and have to jump back to
doing something serious with FlightGear and need to quickly switch back to
my RealWork branch.
On Sat, Jan 8, 2011 at 8:44 PM, Roland Haeder wrote:
I have an FPE to report and a small fix (I already mentioned the FPE in
IRC chat).
The fix is included, with some white-space cleanup.
The FPE patch is a duplicate, since Curt has already committed a
similar fix for this FPE on December
On Sat, Jan 8, 2011 at 10:39 PM, Roland Haeder wrote:
Thanks for including the missing include lines. Jester gave me them in
IRC so please credit him. :)
Too late! Sorry Jester, well done anyway :).
cheers,
Thorsten
I'm not seeing any NaN issues with the TU154b. Though I'm not able to
start it - well, not within 10 minutes at least. :)
There is a minor issue with incorrect property name though. I've
attached a patch.
Anyone in contact with the TU154b designers? There's no email in the
README. Maybe s.o. can
/viewtopic.php?f=4t=4925
On Sun, Jan 9, 2011 at 12:10 PM, ThorstenB bre...@gmail.com wrote:
I'm not seeing any NaN issues with the TU154b.
Hmm, could be on my end, you never know. Did you try a few times, at
some different airports though? I can load a couple times out of a
dozen, but mostly just crashes
Hi,
I've pushed a tiny update for AI traffic to flightgear/next. It improves
performance at airports with busy AI traffic by avoiding repeated
elevation/scenery checks for stationary aircraft. On my system this means a
considerable frame rate improvement at EHAM (many AI aircraft parked at a
On Tue, Jan 11, 2011 at 8:33 PM, Vivian Meazza wrote:
I haven’t seen an problems so far, although I’m not sure why my aircraft
was instantiated at one end of the runway, while the whole of KLM was taking
off from the other. Perhaps we have a mismatch in the runway selection code,
but that
On Sat, Jan 15, 2011 at 4:39 PM, jack.w wrote:
Is this a feature in the latest git version? There have been discussions
over the years on hooking into the IVAO and VATSIM communities. Was not
aware that the connection had been made.
Giving a talk in March at UC Davis on using FlightGear in
On Mon, Jan 17, 2011 at 8:07 PM, Torsten Dreyer wrote:
Hi all,
I just pushed a bugfix to SGMisc::normalizePeriodic(min,max,value).
The method allways returned zero for values less than min instead of
normalizing these values into the given period.
Excellent catch! As so often: when complex
On Wed, Jan 19, 2011 at 10:41 PM, jack.w wrote:
Looking over the wiki page and info. Is Sb747 and AVC limited to MS
windows based machines? Or is there a Linux version as well? Is source
available?
Only the sources of Reed's FlightGear interface (SquawkGear) is available,
but not those
On Thu, Jan 20, 2011 at 4:56 AM, Jacob Burbach wrote:
Was just playing around a bit on MP and noticed that aircraft located
in directories specified with --fg-aircraft do not seem to get picked
up by multiplayer. The pilot list shows them as aircraft not installed
in the pilots list, and you
On Thu, Jan 20, 2011 at 6:22 PM, Jacob Burbach wrote:
Oh...but previously we had discussion (December?) in regards to IO
permissions 'not' working if you used an Aircraft directory directly
and had to use only a directory 'containing' an Aircraft directory.
This must be a fairly recent change
On Sat, Jan 22, 2011 at 2:47 PM, Harry Campigli wrote:
If so what is the best version of OSG to install as I have seen numous
posts here and on forums pertaining to changes of OSG of late?.
The OSG 2.9.x are developer releases. I think 2.9.11 isn't even released
yet, so that's the bleeding
On Sat, Jan 22, 2011 at 10:36 PM, Andreas Gaeb wrote:
I've been looking a bit into the NaN issues. A way to produce them on my
system is to reset JSBSim aircraft, although it happens only about every
fifth time on average, and there are at least two different places in
the code where the NaN
On Sun, Jan 23, 2011 at 12:51 PM, Andreas Gaeb wrote:
IIRC, gcc has a default initialization routine that sets new variables
to zero unless they are explicitly initialized like
int a=1;
Yes, but that's only the case for global and static variables. The start-up
code initializes the memory
On Sun, Jan 23, 2011 at 3:44 PM, Geoff McLane wrote:
And I am not so sure MSVC even zeros static variables,
unless specifically set to NULL/0, unlike as suggested
for gcc, thus say :-
static char * cp;
void func() {
if (cp == NULL)
cp = malloc(val);
can also be a problem...
On Sun, Jan 23, 2011 at 4:57 PM, Jon S. Berndt wrote:
I'd like to find a way to reinitialize an instance of JSBSim in FlightGear
without having to destruct it and reinstantiate it. A couple of years ago I
changed the construction process and separated out a reset/reinitialization
feature to
On Sun, Jan 23, 2011 at 9:13 PM, Andreas Gaeb wrote:
ok, I found the cause for this one. FGPropagate's members
LocalTerrainRadius, SeaLevelRadius and VehicleRadius are not initialized
in the constructor but only later in InitModel(). FGInitialCondition
Andreas, thanks a lot for debugging this!
On Mon, Jan 24, 2011 at 8:43 PM, Olaf Flebbe wrote:
MSVC implements proper initialization of static variables.
http://msdn.microsoft.com/en-us/library/0x80hh2d%28v=VS.90%29.aspx
If you do not explicitly initialize a global static variable, it is
initialized to 0 by default, and every member
On Mon, Jan 24, 2011 at 9:01 PM, Curtis Olson wrote:
If I do a build of the next branch,
then switch to the releases/2.2.0 branch, I still inherit all the build
object files from the other branch. So then I have to do a complete make
clean; make for simgear and flightgear each time I want to
On 24.01.2011 22:49, James Turner wrote:
Perhaps another approach would be to do out-of-source builds. I think
automake/conf should support that, although it's been a while since I've
tried it.
Cmake is very good at out-of-source builds :)
Hmm. The out-of-source builds alone don't really
On 30.01.2011 14:55, Bertrand Coconnier wrote:
Please find attached a patch that fixes bugs #47 and #184. It restores
functionality of command line arguments --vc, --roll-deg, --pitch-deg,
etc. Note also that this patch has also a positive side effect : it
restores functionality of the
On 31.01.2011 20:19, Alan Teeder wrote:
With current Simger GIT and OSG SVN I am seeing this.
https://sourceforge.net/mailarchive/forum.php?thread_name=20110123021352.679925de%40celsius.localforum_name=flightgear-devel
So, OSG 2.8.3 (stable release), OSG 2.9.10 (latest dev release), or OSG
SVN
On 01.02.2011 13:09, henri orange wrote:
Hello devel members,
Is it just me ?
With git today, i have lost the panning feature with Helicopter view.
My fault. Checked the wrong axes when I fixed an issue with tower- and
chase-view panning. Fixed in latest GIT.
Thanks for the report.
On 30.01.2011 14:01, Alexey Varjat wrote:
Please find attached patch for fix animation in existing Fokker-50 AI
model (fgdata/AI/Aircraft/Fokker-50/*xml).
Thanks Alexey, looks good to me: the AI Fokker 50s now have their gear
extended when on ground (much better than seeing them hovering
On 03.02.2011 10:54, Alexey Varjat wrote:
It's pure animation fix:
- Gears and lock bars (up and down just after take off/before landing)
- ruder
- ailerons
- elevators
- flaps
- propellers (0 rpm while stands for both engines, low rpm for one
engine and stopped blades for second one
Hi,
probably spotted the cause for the reported reset crash: it's the same
as already reported before - targeted by this earlier patch:
http://www.gitorious.org/fg/flightgear/commit/287cc74965e11ff3888117a9d9b88ed2bdbb9252
This patch unties all JSBSim properties prior to reset. However, it's
On 05.02.2011 16:21, ThorstenB wrote:
I'm currently testing a different patch for the same issue: instead of
untieing all properties below the /fdm/jsbsim (only), I added a list
to JSBSim's FGPropertyManagager, so it keeps track of all the
properties it has actually bound. It can then use
On 05.02.2011 18:54, henri orange wrote:
,
I get an error at build
screen-dump.cxx:(.text+0x276): undefined reference to
`osg::Referenced::signalObserversAndDelete(bool, bool) const'
/usr/local/lib/libsgmisc.a(PathOptions.o): In function
`simgear::makeOptionsFromPath(SGPath const)':
Hi Betrand,
thanks for your patch. Only one comment on your patch though...
On Sun, Feb 6, 2011 at 1:08 PM, Bertrand Coconnier bcoco...@gmail.com wrote:
* I would rather make tied_properties a list of SGPropertyNode* rather
than a list of strings (same as above : internal JSBSim stuff)
I don't
On 06.02.2011 15:07, Jon S. Berndt wrote:
That works. Sort of. But it's trying to patch JSBSim.cxx which we no longer
have in JSBSim standalone.
Patch looks good and is pushed to FlightGear/next now (so our
JSBSim.cxx is also updated now). Thanks Betrand!
PS: I've made several reset tests,
On 08.02.2011 20:40, Torsten Dreyer wrote:
No sweat - 2.2.0 is not affected. This is because of the TankProperties
I'll try to come up with a solution but that might not be before the weekend.
And, always seeing the positive side, this might be a great opportunity
to have more people testing
On 11.02.2011 16:41, Curtis Olson wrote:
In addition in an external fly-by you could hear the sound moving
from one speaker to the other which was really cool. Now that I think
about it we may have lost that positional capability in the fly by so
I don't know if positioning the sound
Hi,
there are two fixes concerning the tower positions at EDLL and EGLL in
the bug tracker (see attached files EDDL.twr.xml and EGLL.twr.xml).
Can someone update the scenery / TerraSync database with these files
please - and take care of these issues:
On 13.02.2011 14:59, Martin Spott wrote:
Will check. Last time I looked at the proposed change for EDDL it
seemed to me that the requested 'fix' was inappropriate because the
tower positions was correct. Therefore I'm a bit cautions when people
submit Scenery-related bug-reports and declare
On 14.02.2011 07:58, Hal V. Engel wrote:
When working on this from an aircraft that is not located in $FG_ROOT
(IE. my clone of fg-data using fg-aircraft=my fgdata clone/my
aircraft) I was getting file not found errors. At first I though that
perhaps I had a typo or something similar in my
On 15.02.2011 13:41, Tim Moore wrote:
I've checked in fixes for this change in osgDB:DatabasePager to the
SimGear and FlightGear next and releases/2.2.0 branches.
Still doesn't compile with OSG = 2.8.5. We also need the patch that
Bertrand sent yesterday, i.e. the #ifdef logic for the
On Thu, Feb 10, 2011 at 8:05 PM, Andreas Gaeb a.g...@web.de wrote:
Hi Henri,
I think I found the error, it was in JSBSim's FGForce class. I've
proposed a fix on the JSBSim-devel mailing list.
Best regards,
Andreas
Hi Andreas,
had a look at the patch you suggested on the JSBSim list
Hi Andreas,
had a look at the patch you suggested on the JSBSim list
(http://sourceforge.net/mailarchive/attachment.php?list_name=jsbsim-develmessage_id=4D5436B3.10606%40web.decounter=1).
However, I looking at the code it seems calling these InitMatrix in
the FGForce constructor shouldn't
On 20.02.2011 15:40, Curtis Olson wrote:
I know there is one android/flightgear app that serves as a remote
control for flying FlightGear via your android phone--perhaps that is
what you found? It uses the network interface which provides good
separation of application licensing.
Yes no.
On 20.02.2011 16:18, George Patterson wrote:
This site offered the FlightGear (ProFl*Sim) package for Android until
a few hours ago:
http://de.appbrain.com/app/flightgear/com.flightgear
Anything like this one?
http://www.appbrain.com/app/alni-flightgear-control/org.alni.android.fgfs.control
On 20.02.2011 17:27, Michael Sgier wrote:
let me know if anyone can buy it and show the source. I really was
surprisedi never would have given this guy such programming knowledge.
In fact i'd want to look at that but am currently stuck at native c++
glut via Android's
NDK. Probably it
Hi,
I just pushed a new instrument to next: we now have a TCAS device.
It's a new module providing aural alerts for conflicting traffic. It's
also able to drive TCAS displays, since aircrafts' threat-levels are
exposed to the property tree. The existing wxradar instrument is
updated accordingly,
On 27.02.2011 15:48, Geoff McLane wrote:
On Sun, 2011-02-27 at 14:06 +0100, Roberto Inzerillo wrote:
Well, it works ... but the telnet connection is very slow
and that slows down every intercation, it makes it far less than realtime
I quickly added some 'timing' to my telnet access,
through a
On 27.02.2011 21:18, Gene Buckle wrote:
I for one, do NOT welcome our new Vichy FlightGear Overlords. Zey hav
vays of makingink you comply.
Until you mouth-breathing back-biters understand the concept of no harm,
no foul, I don't want to have a thing to do with you.
*« Bravo, vous avez gagné 1
On 03.03.2011 09:47, thorsten.i.r...@jyu.fi wrote:
The total time to load a configuration is really proportional to
(number of objects) x (texture size of a single object)
So maybe the textures aren't really shared. What's worse - and slightly
related: I ran a memory analysis some weeks ago,
On 03.03.2011 20:51, Torsten Dreyer wrote:
I'm currently busy with other stuff. But checking on what's going wrong
with loading/unloading clouds and MP models may be worth a closer look.
There was a fix for a MP memory leak approx. two weeks ago:
On 07.03.2011 22:49, Roberto Inzerillo wrote:
I'm getting results with Arduino and FGFS, at least in a Linux
environment, that's good. But I will just shortly mention there's
something broken in the Windows binaries.
You mentioned using \n as a line separator in an earlier email. One
common
On 18.03.2011 17:50, HB-GRAL wrote:
Today I checked the current fgdata/Aircraft folder for sizes. It’s about
4,3 GB here. Nice.
Some of this files are .gz already, when I .gz the rest I get another
100 MB, or in other words I get two MiG-15 or another p51d.
Nice statistics! Maybe this
Hi all,
I'm seeing an issue with the instant replay feature which seems to
affect JSBSim aircraft. The actual replay works, but once replay is
finished, the sim locks up or goes wild when trying to resume normal
flight. Looks to me as if the FDM was somehow messed up by the replay.
The FDM's
aircraft?
cheers,
Thorsten
On Sun, Mar 20, 2011 at 12:48 PM, ThorstenB bre...@gmail.com wrote:
I'm seeing an issue with the instant replay feature which seems to affect
JSBSim aircraft. The actual replay works, but once replay is finished, the
sim locks up or goes wild when trying to resume
Quiet?? Who said quiet? :-)
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
On 21.03.2011 21:04, HB-GRAL wrote:
Just to report: It’s a OSG 2.9.9 issue on OSX, was going back to 2.9.7
and all works fine. Also the keyboard input.
(I am a victim of the wiki too now :-P , I wrote myself months ago 2.9.7
is needed and someone changed requirement for OSX 10.6 to OSG 2.9.9.
On 22.03.2011 00:08, HB-GRAL wrote:
I just noticed though, that a number of wiki pages again returned to
recommend the use of latest OSG-svn*sigh*. I don't know why people keep
recommending that...
Because it is valid;-) Maybe not trunk, thats always dangerous, but
2.9.9 seems to work
On 22.03.2011 05:24, Robert wrote:
Ingame (insim) I notice a small stutter that happens once every second.
Did anybody of you guys notice the same thing?
What can we do about it?
I thought it might be something like a timed task. (reading from hard
disc + malloc)?
Please, could someone tell
On 22.03.2011 23:54, Tim Moore wrote:
5, maybe worst: osg plugins which load 3d models seem to load textures
directly and store them... somewhere. So no caching, if two models use
the same texture it gets always loaded, no matter what.
This should not be true in general; the images should
Hi,
I've pushed an update to sg/fg/fgdata which enables a (so far well
hidden) feature of our subsystem manager to capture timing statistics.
It''s now configurable at run-time. Use Debug - Toggle Subsystem
Statistics to enable/disable. It prints min/max/average and
std-deviation for each of
On 23.03.2011 23:42, Csaba Halász wrote:
I have found that feature earlier:)
Also I have actually removed some subsystems, but to no avail.
Let's see if somebody can produce other results.
Yes, let's see what people come up with :).
I actually see one submodule which produces some jitter. But
On 23.03.2011 23:22, Bertrand Coconnier wrote:
Attached is a patch that fixes this bug (#294 in the bug tracker). As
far as I could test, it restores the functionality of the instant replay
while keeping the restart feature (CTRL+SHIFT+ESC) functional.
Furthermore I have implemented the 2
On 24.03.2011 14:33, Robert wrote:
Timing summary fornasal.
- mean time: 0.04 ms.
- min time : 0.00 ms.
- max time : 2.05 ms.
- stddev : 0.24 ms.
I don't think we have to dig into nasal code like Franz suggested
(please correct me if I'm wrong)
On 24.03.2011 23:54, Robert wrote:
As you can see Nasal scripts aren't used at all.
No, there are several generic Nasal scripts loaded independently of any
aircraft configuration files.
I checked my system and saw timers from the mp_broadcast.nas (which is
also active when MP is disabled),
On 26.03.2011 06:27, Robert wrote:
However, the garbage collector does a complete scan of all Nasal
objects to detect and remove unreachable elements. So, the more
Nasal data elements we have, the worse the jitter gets. Large
Nasal data structures will eventually break every
On 26.03.2011 10:03, Tim Moore wrote:
Reference counting doesn't provide a strong performance advantage over
conventional garbage collection, and a reference-counting scheme can
take an unbounded amount of time. Reference counting schemes that do
have real-time or bounded behavior are very
On 27.03.2011 13:48, HB-GRAL wrote:
I get an error in /Nasal/fuel.nas with current fgdata git:
Time to update fg/next. You're probably missing this commit:
http://www.gitorious.org/fg/flightgear/commit/0114fd962e7450b080e580fe67414ca43cd99bd7
cheers,
Thorsten
Hi,
here's a few more comments/hints/warnings on Nasal and simulation
performance in general.
First of all: it's not meant _against_ anybody. It's great to have a
tiny scripting engine in FG. It's great to have an option for custom
extensions. And we're certainly seeing very nice examples
On 31.03.2011 17:01, Robert wrote:
Hi everyone,
I'd like to share some thoughts with you on how we can improve the
replay system.
Right now only the last minute is recorded at full precision. After
that minute we get a precision of 1 fps. And after 10 minutes we get a
precision of 1
1 - 100 of 324 matches
Mail list logo
