On 07.05.2011 10:20, Alan Teeder wrote:
Ever since the atmospheric scatter patches went in I have had black sky,
instead of blue.
If I turn on material shaders, then there is a small area of blue close
to the horizon, but that is the best I an achieve.
The attached is from my TSR2 cockpit
On 18.04.2011 23:13, Maik Justus wrote:
By the way: I would prefer to use the old default values for the gear
solver. The spring constants of a gear should not be a function of the
approach fuel settings. Maybe some gears would need some tuning with the
patch otherwise. The
_approachWeight =
On 03.05.2011 19:42, Curtis Olson wrote:
The code seems pretty definite that it would execute here, so it's odd
that you are getting NULL there ... unless the sgmgr-find() call is
returning null for you? Or if like you say, somehow our source trees
have diverged. But I do think I'm 100%
On 18.04.2011 14:51, Adrian Musceac wrote:
On Monday, April 18, 2011 01:09:56 Heiko Schulz wrote:
I had a fix locally but with the patch fixing the YASim issue I have now to
begin again. I see the problem in the airfoil, but a change to this means
that I have to change a lot of other
On 16.04.2011 21:16, Anders Gidenstam wrote:
If I'm not mistaken the particles issue has been around since we got
particles, so it is apparently not that bad (leak and race
condition) in practice.
Ok, thanks! I've create a bug issue as a reminder, in case someone else
noticed the issue some
Mixing spaces and tabs is really ugly - I think cleaning up such a mess is good.
Many people like tabs, but disadvantage is that everyone uses a
different tab settings. Most editors I know use 4 or 8 spaces/tab as
the default. But since it's different for everyone, I personally
prefer spaces - at
Hi,
had another look at memory consumption. The FG multiplayer (=AI)
aircraft classes seem fine - they are created/removed as expected. But
there are problems with some of our OSG-based simgear classes: they
are never removed at run-time - hence memory is eaten up.
Problems start at
On 15.04.2011 22:22, Bertrand Coconnier wrote:
Yes, a bug fix has been committed to fix instant replay with JSBSim
aircraft (bug #294)
https://gitorious.org/fg/flightgear/commit/11320e6b008eb85b8dff66a137f671743cc04580
I think it should be applied to 2.2.0 as well.
Ok, thanks Betrand! That
On 16.04.2011 02:06, Pascal J. Bourguignon wrote:
The props data protocol ls command has a problem: there's no way to
determine that its output is complete (unless we use a timer, which
would mean that all ls commands would suspend the client for the time out
duration).
I'm proposing to add
On 16.04.2011 16:24, Anders Gidenstam wrote:
On Sat, 16 Apr 2011, Anders Gidenstam wrote:
Hmm.. I should have added that I looked at this in early September last
year so it is not fresh in my memory.
IIRC the current code already does the fundamentaly unsafe operation of
adding items to a
On 15.04.2011 11:11, Andreas Gaeb wrote:
The input value lists seems to fulfil both conditions (SGSharedPtr
pointing to SGReferenced), so in theory, automatic deletion should work
here. Still, valgrind complains. Could the problem here be related to
calling the componentForge functor?
On 14.04.2011 18:22, Curtis Olson wrote:
Yeah, we should get back to that. What is the current status? I have
spend a lot of time doing the prepatory work for an eventual release
during my holiday, but apparently no release has happened during my
absence. Are there still any
On 13.04.2011 13:46, Frederic Bouvier wrote:
To reduce memory footprint caused by model caching, I added this code to the
begining of the main function of fgrun :
osgDB::Registry* registry = osgDB::Registry::instance();
registry-setExpiryDelay( 0. );
I suspect we can control the
Hi,
I'm having joystick issues: on start-up, all axis are in
left-most/lower-most position (reporting -1). Only once I have moved
each axis for the first time, do I get valid positions. Hardly
noticeable with most planes, since -1 means throttle is idle - so full
left-rudder/pushed-aileron
On 11.04.2011 17:29, Francesco Angelo Brisa wrote:
well ,I will make some experiments on 2.9.10 if it finds out to
compile easly and to be quite stable, I will make it the default
behaviour, with 2.8.3 as stable option.
When we last discussed this (February), 2.9.9 was reported to be
On 10.04.2011 13:29, Geoff McLane wrote:
As far as I am aware we can _NOT_ presently use
later that OSG-2.9.9 ;=((
Yes, we can. But 2.8.3 + 2.9.9 are used by the automatic download
compile script, since these versions are known to work fine. And as we
noticed, we have a lot of people running
On 10.04.2011 15:02, Geoff McLane wrote:
On Sun, 2011-04-10 at 14:34 +0200, ThorstenB wrote:
As far as I am aware we can _NOT_ presently use
later that OSG-2.9.9 ;=((
Yes, we can.
Huh? Then WHY does Arnt have a LINK problem with OSG-2.9.11?
I don't know. The error Arndt is seeing
Maybe someone could do some tests when changing the setting
(SGPagedLOD.hxx:56) from CACHE_NONE to CACHE_IMAGES or even to
CACHE_ALL (then recompile/install sg+fg). Would be interesting to know
how this changed loading times, run-time fps and memory consumption.
After 30 minutes more of
On 03.04.2011 16:18, Torsten Dreyer wrote:
Me, too. I had a few coredumps with the 4-nvidia-cards, 8 monitors
(multithreading=automatic) setup since I had that enabled. I was not able to
backtrace and blame it to the CACHING-Option, however. So this might just be a
random correlation.
In fact
Roberto,
though on the wire I send precisely 7 digit numbers: 3 digits
followed by a dot and 3 decimal digits);
As you describe correctly, you're transmitting strings (= series of
ASCII characters).
typeint/type
For an input protocol this is the _target_ type. With int your
_string_ is parsed
Hi,
I've pushed an improvement to our Nasal script loading process. Should
help with some of the issues we recently discussed.
1. Nasal scripts can now be grouped into submodules stored in separate
folders (fgdata/Nasal/MyModule/*.nas). This has several advantages:
- Better structure. Things
On 30.03.2011 08:31, thorsten.i.r...@jyu.fi wrote:
How do arrays and objects count? If an object counts as one reference,
then it's very efficient to use I guess - if every key in the hash counts
as one, then certainly less so.
Right. I believe arrays and hashs may both be implemented
On Fri, Apr 1, 2011 at 12:34 AM, Curtis Olson curtol...@gmail.com wrote:
So, it might be a good idea to record all properties in an interval of a
few seconds only, while only recording properties that have actually
changed with every frame. That should allow to drastically reduce the
amount
Every standby-mhz value Arduino is sending has been previously formatted so
that it has at most three decimals, something like that: 139.775 or 129.675.
Problem is FGFS shows /instrumentation/comm/frequencies/standby-mhz as
139.7749939 or 129.6750031. There's something wrong with that and I
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
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 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 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 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 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
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.
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
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
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 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 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
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 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
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
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 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
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
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,
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)':
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
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 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 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 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 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 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 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 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 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 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 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 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 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
/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
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
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
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.
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 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
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 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 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.
201 - 300 of 324 matches
Mail list logo