Tim Moore wrote:
> I've committed a version of Till Busch's terrain effects, as seen at LinuxTag.
> I know that he hasn't finished tuning them, and I've changed his landmass
> effect
> to use the base terrain texture, which he's not entirely in agreement with :)
> Nevertheless, they are great exa
Torsten Dreyer wrote:
> Hi,
>
> There are some possible floating point exceptions in oursun.cxx:
> in SGSun::update(double,double) there is
> sun_exp2_punch_through = 2.0/log(visibility);
>
> visibility is assigned the new_visibility _before_ new_visibility is clamped
> to 100 % 45000. Because
Victhor Foster wrote:
> Want a backtrace?
No, it's expected behavior.
Erik
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment
Victhor Foster wrote:
> I tried applying the patch and editing it to change "float n=0.06 +
> dot(nvL[0], a);" to "float n=0.06 + dot(nvL, a);", but my framerate
> hasn't improved. What's the problem?
>
Probably that the shaders work differently than I expected and that the
error triggered
Randall Green wrote:
> Victhor,
>
> You are absolutely amazing! But now I get file not found on jconfig.h.
> Is it needed? I see the code looks like this:
>
> #ifndef JCONFIG_INCLUDED/* in case jinclude.h already did */
> #include "jconfig.h"/* widely used configuration options */
>
I wrote:
> Ahh, that line should read:
>
> float n=0.06 + dot(nvL, a);
>
> instead of:
>
> float n=0.06 + dot(nvL[0], a);
Which brings the frame rate back to what it was :-/
Maybe it might be a good idea to specify which of the effects you want
to turn on or not? Chances are I could care less
> Martin Spott wrote:
>> This patch is probably not for everyone. At my end I'm reading the
>> following message in the terminal:
>>
>> FRAGMENT glCompileShader "" FAILED
>> FRAGMENT Shader "" infolog:
>> 0(27) : error C7011: implicit cast from "float" to "vec4"
>>
>> glLinkProgram "Shaders/landma
Martin Spott wrote:
> This patch is probably not for everyone. At my end I'm reading the
> following message in the terminal:
>
> FRAGMENT glCompileShader "" FAILED
> FRAGMENT Shader "" infolog:
> 0(27) : error C7011: implicit cast from "float" to "vec4"
>
> glLinkProgram "Shaders/landmass.vert;
Torsten Dreyer wrote:
> With this patch, I get a number of
>
> No render bin number specified in render bin section
> No render bin name specified in render bin section
I already got them before the patch..
Erik
--
Let
Tim Moore wrote:
> I've committed a version of Till Busch's terrain effects, as seen at LinuxTag.
> I know that he hasn't finished tuning them, and I've changed his landmass
> effect
> to use the base terrain texture, which he's not entirely in agreement with :)
> Nevertheless, they are great exam
Stuart Buchanan wrote:
> Hi All,
>
> I have the pleasure to announce that the latest edition of the FlightGear
> Newsletter is now available:
>
> http://wiki.flightgear.org/index.php/FlightGear_Newsletter_August_2009
Looking at the custom made scenery screenshots I must say that hand
altered
leee wrote:
> I'm not really thinking in terms of 'threading' at all, which I
> think is a very limited and half-house sort of technique. But
> neither though do I think it needs to be thought of as a pure real
> time system. Rather, I'm thinking in terms of the external FDM
> mechanism al
Anders Gidenstam wrote:
> IMHO the one important threading benefit is if we could get all of the
> rendering off the main simulation loop, meaning that the model runs
> independent of the presentation. (Ok, expensive environment eye candy
> like the traffic manager or wild fire CA would also
Jon S. Berndt wrote:
>> Erik Hofman wrote:
>>> Apperently this was needed to compile with MSVC 9 (patch was added by
>>> Fred twice). I probably should have made a test build before
>> committing
>>> to CVS.
>> Which wouldn't have revealed
asma ben zakour wrote:
> The problem seems to be that the xml file I put into data\protocol is looking
> for some plane informations it cannot find and FG crashes...
I wrote:
>> I must admit I never tested that..
>> With a bit of luck I might be able to test for that this weekend.
>> When I find
asma ben zakour wrote:
> Tahnks for the answer, actually I don't want to replay the flight, but
> extract information from the output file I get from FG.
> The problem seems to be that the xml file I put into data\protocol is
> looking for some plane informations it cannot find and FG crashes..
asma ben zakour wrote:
> Hi every one !
>
> I'm a Phd Student on data mining and prognostic , and I want to recover
> some aircraft flight data from FG for testing algorithms .
> I writes an XML File *thesis.xml* ( in the *data/protocol* FG directory
> ) witch allow to have some information f
It's committed. Thanks.
Erik
Nicolas Quijano wrote:
> Hi all, can't build in debug atm on Doze, as a recent change in
> simgear/screen/RenderTexture.cpp breaks non X11 builds because of non
> isolated GLX code.
> The attributes code should have been wrapped (tsk tsk 8p)
>
> This is a bandaid,
Erik Hofman wrote:
> Curtis Olson wrote:
>> I haven't looked at the code, but generally, I think it makes sense
>> (when dealing with live data) for the generic protocol to enter a while
>> loop and read data until there is no more available. That way if the
>&g
Curtis Olson wrote:
> I haven't looked at the code, but generally, I think it makes sense
> (when dealing with live data) for the generic protocol to enter a while
> loop and read data until there is no more available. That way if the
> sender is sending at a higher rate or FlightGear gets beh
Peter Völk wrote:
> Hi All,
> I'm trying to put my own data into FG, with the native fdm and the
> generic input protocol at the same time. My problem is, that fdm works
> fine, but the data is send via UDP over the generic protocol has some
> kind of lag or rather delay. When I pause sending
Petr Gotthard wrote:
> Let me advocate the idea:
> I'm proposing a generic interface. If you look from the other side, it's a
> possibility to easily implement a new I/O module for FlightGear. To help
> people that might be interested to extend FlightGear but do not want to
> recompile the who
Petr Gotthard wrote:
> To follow the "do things right" rule I think it would be great to implement a
> generic interface for standalone I/O modules. Both Micro$oft FSX and X-Plane
> have such interface. The M&S HLA users would just need to build a shared
> module (.dll or .so) for a particular
Martin Spott wrote:
> No problem, maybe the changed file just didn't make it into the CVS
> commit. I'm very cautious these days for the sake of not having to deal
> with this sort of stuff once we're set up at LinuxTag ;-)
Fair enough.
Erik
gcc can't be trusted.. I did a test compile here :-(
I'll fix it.
Erik
Martin Spott wrote:
> Hi Erik,
>
> Erik Hofman wrote:
>> Update of /var/cvs/SimGear-0.3/source/simgear/screen
>> In directory baron.flightgear.org:/tmp/cvs-serv19946
>>
>> Modifi
Curtis Olson wrote:
> I haven't had a chance to contact Butterfly Media myself, but perhaps
> someone here would be willing to pull lead on that?
>
> http://www.butterfly-media.co.uk/index.htm
>
> This weekend I was contacted by an ebay seller. I did a quick google
> search and found that hi
Erik Hofman wrote:
> If this code is just used by a utility that is useful for developers
> only (normalmap) then I'd move the code oevr to that specific directory
> and leave it at that.
I had a few spare minutes and the code is moved o
Curtis Olson wrote:
> Can we just quote Mark Kilgard's comment in that thread that
> modification is fine? I like Debian and I ran their distribution on my
> machines for many years. I admire how carefully they follow through
> with these licensing issues ... but my word ... no wonder their
Looking at the code it is heavily modified in the mean time, although
parts of the original texture loading code are still in place.
Erik
--
Are you an open source citizen? Join us for the Open Source Bridge conference!
Curtis Olson wrote:
> I don't see any thing in the license terms that states we cannot modify
> the code. Are we running on the assumption that we can only do what is
> expressly allowed? Perhaps Erik Hofman should address this. As I look
> at the code I see it's a fu
Martin Spott wrote:
> Hi Erik,
>
> Erik Hofman wrote:
>> Update of /var/cvs/FlightGear-0.9/source/src/Network
>> In directory baron.flightgear.org:/tmp/cvs-serv24469
>>
>> Modified Files:
>>generic.cxx generic.hxx
>> Log Message:
>
>
Tim Moore wrote:
> I mostly agree with this, though I continue to maintain that the new types
> are fully in the spirit of the property system, moreso than array types would
> be. I'd also suggest that no one here knows the right answer to this question,
> making the option of playing with the new
Curtis Olson wrote:
> Hi James,
> At the end of the day, the "correct" approach really depends on what you
> are trying accomplish (what values and in what format are you trying to
> compute?)
Also, there is a difference between the value in the property tree
(which is just a nifty way to loo
Vivian Meazza wrote:
> Torsten Dreyer wrote:
>>> So - I am just about to commit what I have done so far.
>> And now i did.
>>
>> If anything is broken or does not work as expected, please shout.
> So much seems broken right now, might be hard to spot :-)
It's not so much that things have broken
?? wrote:
Hi,
I know OSG can load many types of model, but in FlightGear, why do we
use AC3D model type. We know that OpenFlight format model can define
DOF, it should be easy to use than AC3D. And there have many other model
types, why do we just use AC3D model type?
Historically this
This was posted in the forums by one of the people involved in the
project. It's really nice to see FlightGear used in projects like these.
http://alfonsodg.wordpress.com/2009/05/24/mi-17-helicopter-simulator-flightgear-core-floss-inside/
Erik
---
Alexis Bory - xiii wrote:
> Note: In the case of the tanker and for my particular needs, it is a
> very, very, very minor wish... It is just a matter of knowing if adding
> this feature to FG would be a big deal in the core code, and also if
> this elevation/AI problem is encountered in other ma
Now you're way ahead of me, I'm still at the stage where I want to see
if it really helps as much as I hoped it would.
Erik
--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning
Lee Qid wrote:
> Hi there,
>
> and excuse me for butting in on this one, but the post just rung my alarm
> bell.
>
> Am I interpreting your post correctly? You want to implement your own
> XML parser.
No, I have already.
> Wouldn't that be like reinventing the wheel? There are tons of them
>
Let's clear things up a bit (I hope):
1. I'm not planning rushing the code into CVS since I know the XML
reader code is one of the most important areas of FlightGear. Get it
wrong there and all sorts of pesky problems can arise.
2. The Expat code (along with EasyXML code) will remain available
Hi Gene,
Good to see you back again, how's the F-15 project going?
Gene Buckle wrote:
> Were you born a complete jerk or is this something you learned in school?
Thanks for standing up for me, but I'm used to direct and to-the-point
comments (I'm Dutch you know). I can see why people might find
Melchior FRANZ wrote:
> * Erik Hofman -- Saturday 09 May 2009:
>> The downside of this code is that it is not 100% validating (so
>> it might accept xml syntax errors where expat didn't) and it
>> doesn't support DTD's.
>
> Hmm ... so it's sloppie
Hi,
As some of you may know I have been working hard the last few weeks to
improve a seamingly not very important utility called xmlgrep in the
FlightGear utilities directory.
The reason for this was that the way this code works differs from the
expat xml reader that FlightGear has been using
Hi Detlef,
Could you also add this to the wiki?
Erik
Detlef Faber wrote:
> Description from the logo.xml file:
>
> This is a generic square shaped Logo which can be referenced by any
> Aircraft Model as a submodel.
-
gerard robin wrote:
> Yes it is difficult to trap these nan which are coming ( + or -
> randomly ? ? ? , though, getting trouble with carrier) ), and when we get it
> the system is closed to be frozen , with black screen, and command line
> overflowed with messages.
> And when i tried with
Torsten Dreyer wrote:
>> Erik
> You are right - sorry. It is corrected. I am sure there was no evil mind
> behind that.
Probably not but I felt it was important to point out.
Anyway, thanks for fixing it.
Erik
--
Stay o
Torsten Dreyer wrote:
> -// Written by David Culp, started Feb 2004.
> +// Original by Written by David Culp
> //
> -// Copyright (C) 2004 David P. Culp - davidcu...@comcast.net
> +// An attempt to refine the thermal shape and behaviour by WooT 2009
> +//
> +// Copyright (C) 2009 Patrice Poly (
Hi Patrice,
Patrice Poly wrote:
> I am declaring :
>
> _earth_radius_node = fgGetNode("/position/sea-level-radius-ft", true);
>
> props->tie("debug/earth-radius-ft",
> SGRawValuePointer(&earth_rad_ft));
> with earth_rad_ft = _earth_radius_node->getDoubleValue();
^^^
Jon Stockill wrote:
> Sunsets look very nice, but this looks a bit odd, I've not noticed it
> before, so I'm not sure if it was introduced with this change, or an
> earlier one, the top of the skydome seems to have some rather odd shading:
Hmm, I've updated CVS to fix the problem by removing ab
Jon Stockill wrote:
> Sunsets look very nice, but this looks a bit odd, I've not noticed it
> before, so I'm not sure if it was introduced with this change, or an
> earlier one, the top of the skydome seems to have some rather odd shading:
>
> http://courgette.jml.net/~jon/fgfs-sky-001.jpg
> h
Mathias Fröhlich wrote:
> Good morning,
>
> On Sunday 12 April 2009 10:24:09 Erik Hofman wrote:
>> oops, that's a left over debugging printf in simgear/scene/sky/dome.cxx
>> I'll commit a fix soon.
> Oops, concurrent debugging.
> I am looking into the r
Vivian Meazza wrote:
> Erik
>
>> After a request in the forum for a nice pink sunset I decided to update
>> the sky coloring a bit.
>> The fog color now transitions into the sky dome which gives a way better
>> result (imho).
>> (changes are both in SimGear and FlightGear).
>>
>> Let me know wha
Hi,
After a request in the forum for a nice pink sunset I decided to update
the sky coloring a bit.
The fog color now transitions into the sky dome which gives a way better
result (imho).
(changes are both in SimGear and FlightGear).
Let me know what you all think.
Erik
--
Stuart Buchanan wrote:
> Tim Moore wrote:
>> I'm trying to give your generic approach a chance.
>
> I may be mis-interpreting your words, but if this means you're actively
> investigating coding your new changes without vectors, then you deserve
> many heartfelt thanks for putting extra effort
Tim Moore wrote:
> Erik Hofman wrote:
>> There is still something that isn't addressed with his proposal.
>> At this time all types can be converted to all other types. It would be
>> easy to convert any float/doubles or integers to a one element array,
>> but
Melchior FRANZ wrote:
> My announcement to leave was in response to Curt's "green light"
> and vote, to his opinion that the arguments against the change
> weren't strong enough. Had I assumed that this isn't decided yet,
> then I would neither have made the announcement, nor given up. But
> actu
Mathias Fröhlich wrote:
> Catching up with an already heated up discussion.
>
> IMO:
> Tim should go on and include arrays into the property system.
> I even believe that aggregates and more sophisticated types will be something
> good to have.
There is still something that isn't addressed wit
This should now be fixed in simgear/scene/sky/oursun.cxx
Erik
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
h
Vivian Meazza wrote:
> S Andreason wrote
>
>> Erik Hofman wrote:
>>>> Why wait for a NASA Shuttle? There already exist several models to see
>>>> the /interesting/ effects at altitude, some which have changed with the
>>>> new ambient values.
&
Curtis Olson wrote:
> This isn't an argument for or against Tim's proposal in and of itself,
> but it's at least interesting to observe other real world cases that
> are at least partially similar. Has JSBSim run into any problems with
> it's journey down this path?
This has been one reason why
S Andreason wrote:
> Hi Vivian,
>
> Why wait for a NASA Shuttle? There already exist several models to see
> the /interesting/ effects at altitude, some which have changed with the
> new ambient values.
For good or for bad?
(and if for bad what exactly, or as precise as possible).
One proble
Timothy Moore wrote:
> Erik Hofman wrote:
>> 1. Will ambient/r, ambient/g and ambient/b still be supported in other
>> locations besides xml embedded effects en techniques?
> That's my plan.
Ok, that's good to hear.
I think this will eliminate many of the o
Vivian Meazza wrote:
> I've now amended the table to reflect the static offset, and I'm happy with
> the result.
Even at midnight?
I was worried the ambient might be too light with a static offset.
> Do you want proceed with this, or just drop it?
Lets get it right this time.
Erik
-
Melchior FRANZ wrote:
> * Vivian Meazza -- Saturday 04 April 2009:
>> This is how I think it should look,
>
> Does indeed look much better here (on my *still* quite bad monitor ;-).
Alright I've updated the ambient table (multiplied all values by 2.5)
Let me know what you all think with the CV
Curtis Olson wrote:
> I don't have time to follow along with IRC so I can only see what is
> posted to the mailing list, so I very well could be missing key parts of
> this discussion. But honestly, I am really having trouble understanding
> the objection here.
The biggest problem that I wou
Vivian Meazza wrote:
> I'm doing a small adjustment in light.cxx - seems to work:
>
> float ambient = _ambient_tbl->interpolate( deg ) + (0.25 + 0.75 *
> visibility_inv/10);
>
> Not sure that I fancy tinkering around in Data/Lighting/ambient - someone
> has obviously taken a lot of care t
Melchior FRANZ wrote:
> * Vivian Meazza -- Saturday 04 April 2009:
>> I can fix it here, to my entire satisfaction, so if everyone else is
>> happy, don't worry.
>
> I can't really say much about this, as I'm using a rather old and not
> so great monitor that I don't seem to be able to calibrate
There seemed to be a problem with my mail since I noticed in the
archives there were some replies to my previous post about this item.
I've tweaked the values some more and think I've got it just about right
(or good enough) this time.
Erik
-
Heiko Schulz wrote:
> Hi,
> Well, for someone who don't have any ideas or knowledge about shaders, it
> looks really complicated at the first sight. On the other site, it looks a
> bit like the .osg-files, and with a bit diggin in, it would be understandable
> for me at least.
>
> I guess i
Tim Moore wrote:
> If people really don't like the effects syntax, I might be willing to hold my
> nose
> and use the existing property implementation. I'm also not committed to
> having the
> effects properties be of class SGPropertyNode; they might be a subtype.
I have two questions after rea
Erik Hofman wrote:
> After reading the comments I agree with it.
> I'll take some time to adjust the ambient accordingly.
This has been committed to CVS now.
Let me know what you think.
(keep in mind that the darkest ambient color is defined in
data/Lighting/ambient which has not b
Vivian Meazza wrote:
> I'm not clear about how much ambient light there should be in any situation,
> but, to me right now there isn't enough with the default model. The effect
> of visibility on the diffuse and specular setting looks OK in very low
> visibility, but at high visibility it looks ver
Hmm, sitting in the sun today during lunch made me realize that what I'm
really after is probably the effect of looking towards the sun in
comparison to looking in any other direction. The Bright light of the
sun seems to make the ambient light much darker (higher contrast).
Anyhow, Melchior s
Vivian Meazza wrote:
> This is a tough one - I expect you can ask 4 developers and get 5 opinions.
> Here - ambient is much too dark, while specular is about right. But the
> visibility also seems to have far too much influence.
Indeed tough, especially since we still do have models with a wide
Heiko Schulz wrote:
> I'm against this code- I can't really understand what's the intention of this
> code is- destroying glossiness?
Only when it's foggy. On bright clear days it will shine like before.
The real intent is to make it a bit more realistic.
> I would like to see a change of the
Frederic Bouvier wrote:
> Maybe I missed something but the visibility is not related to the distance
> between the viewer and the object. As far as I understand Erik's intention,
> there should be no glossiness in fog or inside a cloud, so setting glossiness
> to 0 when visibility is 0 makes s
syd adams wrote:
> You mean I have to start over fixing my models ? I've only made it to
> "C" ! ;)
Nope, not as far as I know (and i was hoping to prevent that).
If you think it´s incorrect now let me know and I´ ll try to fix it in
the code.
Erik
>
Hi,
I have changed the specular and ambient behavior of FlightGear a bit by
reducing specular highlight at decreased visibility and by increasing
ambient colors at decreased visibility.
This means that, form now on, when testing the color components of an
aircraft it is best to switch to
'fai
gerard robin wrote:
> However, i don't mind if they remain in CVS, and like it has been said, i go
> on to update the same models ( not exactly the same content ), with a lot of
> others new Aircrafts which were never committed within CVS ( because not well
> advanced , or not FG 1.9 compatib
Ron Jensen wrote:
> On Tue, 2009-03-24 at 14:06 +0100, gerard robin wrote:
>> Does that will modify the original Jon's recommendation to start an engine ?
>>
>> Get the external Air compressor resources
>> The engine will spin up to a maximum of about %25 N2 (%5.2 N1)
>>
Csaba Halász wrote:
> On Tue, Mar 24, 2009 at 12:47 PM, Erik Hofman wrote:
>> Specter wrote:
>>> I write patch for changes of JSB turbine starter spin time.
>> Dave just recently committed this patch to JSBSim and I am preparing a
>> new sync between them soon
Specter wrote:
> I write patch for changes of JSB turbine starter spin time.
Dave just recently committed this patch to JSBSim and I am preparing a
new sync between them soon so it'll end op in FlightGear that way.
Erik
-
Frederic Bouvier wrote:
> Is it the whole file ? Are we talking about ten lines or tons of them ?
This was just one example.
Erik
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web
Frederic Bouvier wrote:
> Tim, perhaps if you could show us a real effect file, with the syntax
> you propose, we ( at least I ) could see what we are talking about, and
> the pros and cons of the new syntax.
That was in the original proposal (RFC):
> Proposal: Allow vector types as properties in
Tim Moore wrote:
> Perhaps. I'm not proposing to change the syntax you like. I just want to
> evolve the very useful property system to support the syntax I like.
So far nobody seems to like the idea of abandoning
for a list of numbers. I think you can safely forget about that.
To be honest I
Tim Moore wrote:
> property node aggregates and aggregate C++ types is not a real problem
> coding-wise. I just don't like the current XML syntax.
If this is you main motivation I'm just plain against this.
But I have the feeling that you're gonna regret this comment.
Erik
Tim Moore wrote:
> Erik Hofman wrote:
>> Allright but how would you acces /model/skin/color/red in the new case then?
> What do you mean by "access?" In C++ or Nasal within fg, or in the XML parse
> within
> another app? Why would you want "red" without
Maik Justus wrote:
> Hi,
> Or we do it vice versa. We store the vec3 directly in the property tree,
> e.g.. surface/color, but you can access any components over the property
> tree in the approved way. (surface/color/red, curface/color/blue, ...).
> From telnet, MP, property-browser, etc. eve
Mathias Fröhlich wrote:
> But from my point of view the property tree is also used as a reflection
> framework to reflect objects state into the models/scripting/whatever. From
> my
> point of view, the serialization of the objects into xml is just a special
> case of that reflection stuff. G
Melchior FRANZ wrote:
> How will a VEC3 property be written in an XML file? As
> 123;341;123? Will then every application
> which reads such a file have to have its own (sub)parser for
> certain fields, in addition to using an XML parser?
This is my strongest point to be against it. The property
Mathias Fröhlich wrote:
> Erik,
>
> On Thursday 19 March 2009 09:08:29 Erik Hofman wrote:
>> To be honnest I don't like this action. I've always made sure all color
>> settings were right in the modeller and did'nt adjust them to look nice
>> in FlightGea
Mathias Froehlich wrote:
> Update of /var/cvs/FlightGear-0.9/data/AI/Aircraft/Fokker-50/Models
> In directory baron.flightgear.org:/tmp/cvs-serv2499/Aircraft/Fokker-50/Models
>
> Modified Files:
> fokker50.ac
> Log Message:
> Set the ambient color equal to the rgb color.
> This is what cur
I've been silent in this thread mostly because I'm not very active as a
developer these days, but it got me wondering why one would use lua
instead of nasal.
Searching for 'lua nasal' in google the first hit describes it all to my
opinion:
http://trainofthoughts.org/blog/2007/09/16/lua-popular
The main reason for implementing the property system is that it can
represent the contents of any XML file in memory quite easily.
Erik
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OS
alex wrote:
> Does OpenAL support any other sound file configuration other than .wav?
> I have problems with OpenAL unable to buffer some ..wav files but runs
> fine with other .wav files. Does anyone know of a particular reason for
> this.
> Your thoughts would be appreciated
Like gerard alread
Anders Gidenstam wrote:
> On Fri, February 6, 2009 5:39 am, syd adams wrote:
>> Hello ,
>> Ok, I have everything in the data folder converted to /level-lbs.
>> (The Concorde was a bit of a nightmare) ... :)
>> If someone could commit the patch , I'm ready to commit the data ...
>
> I can upd
Stefan Seifert wrote:
> On Wednesday, 28. January 2009, Jon S. Berndt wrote:
>
>> Is there sometimes confusion as to how or where to apply changes to JSBSim
>> code or aircraft models? Do we need to work on easing the process of
>> integration into FlightGear? More frequent synchs? (we'd need ad
Jon S. Berndt wrote:
> Is there sometimes confusion as to how or where to apply changes to JSBSim
> code or aircraft models? Do we need to work on easing the process of
> integration into FlightGear? More frequent synchs? (we'd need additional
> volunteers, and/or I'd have to step in - I don't wan
Martin Spott wrote:
> Overall, I think some day "the crowd" should start making up their mind
> about wether relying on an externally maintained FDM is still the way
> to go. Developing a copy of the FDM _in_ FlightGear might return a much
> higher benefit at reduced effort.
I more concerned abou
John Denker wrote:
> This morning I did a git-pull and make.
>
> I observe that the new version executes in 855 megabytes under
> conditions where the previous version from a week or two ago
> executed in only 450 megabytes.
>
> That seems kinda extravagant.
>
> Is everybody else seeing the
701 - 800 of 1160 matches
Mail list logo
