Re: [Flightgear-devel] RFC: graphics effects files
On Sun, Apr 5, 2009 at 2:21 PM, Jon S. Berndt wrote: The part that I was unsure about was to what extent FlightGear used relationships between and amongst properties (operations). If properties are used on the FlightGear side for input/storage only, then I’m OK with it as long as the code remains backwards compatible – which, I’m sure, is a given. It can be useful to look at past history as precedence to give some context when evaluating some new situation. In light of that we should notice that JSBSim supports arbitrary vectors and tables of floating point data within it's xml file syntax and has done so since it's very earliest days. This is only part of the picture because as far as I know they don't have a way to store these tables in their property system, but it's interesting to observe that JSBSim has gone partway already in doing something similar to what Tim is proposing. 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? Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
the functionality at all because it'll be trivial to convert from the current property tree representation of the data to the form required by OSG. I still can't see a good reason to make changes to the way the property tree represents data unless the overhead of accessing three or four property tree nodes, instead of just one, has a significant impact on performance. How frequently does this data need to be accessed? LeeE -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
On Sat, Apr 4, 2009 at 3:05 AM, Melchior FRANZ mfr...@aon.at wrote: * Tim Moore -- Saturday 04 April 2009: A couple of weeks ago I was asked for a sample of an effects file that uses my proposed changes to the property system; And a few weeks later I still object to these property changes, and will do so as often as it is brought up again. And for all the same reasons! Hi Melchior, Let me ask this on the list. Since the beginning of time, computers have included the concept of arrays. Since the birth of the property system in FlightGear, it has supported booleans, integer, floating point, and double floating point types. The property system has also always supported character arrays. The property system supports implicit conversions between types if that is asked for, and always makes it's best attempt. But if you ask for something nonsensical or poorly defined, you will get something back based on the rules of the system, but it may not make a lot of sense. If you try to extract the floating point value of a string (aka character array) you get something back based on the rules of the system, but what if you try to retrieve the floating point value of abcdefg. It doesn't make sense, you probably won't get a useful answer although you will get something. It's up to the calling routine to make sensible requests. It's always been that way, it will always be that way. Now, the message I am getting here is that some people think it's unacceptable to also support double or float arrays within the property system. It can't be because arrays are messy because we already support character arrays. It can't be because some conversions wouldn't make sense, because we already have that situation. It can't be because it makes the property subsystem too complex, because Melchior, to be fair, you are the king of creating very complicated systems (with correspondingly high functionality.) I don't mean that as a diss ... I'm just observing that you have put together some highly complex systems full of subtle nuance within the flightgear code base. 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. I fail to see what is going to break, what is going to end, what harm is going to be done. Is there a direct conflict in logic? Is there a non-othogonality in design? Is there some behind the scenes fued going on that I'm (thankfully) unaware of ... in that case I'll quit trying to draw out logical reasons for your objections? I'm married so I'm continually caught trying to find logical explanations where there are none. :-) I'm not suggesting that's the case here, but if it is, we might as well say it clearly so I don't have to waste my time trying to understand what's going on. I asked Tim if it would make sense to just support generic double or float arrays in the property system ... just like we support character arrays. However, he replied that you were even more opposed to that than specific color or position array types. Again, I fail to understand why. I could be easily missing something here, I'm not claiming I have an all seeing eye. But if someone makes an assertion I don't understand, or supports it with reasons that don't make sense to me, I have trouble buying that assertion. I've always had that problem, and it's my own personal failing I know. I think it's a good thing I didn't sign up for military duty here when I was a kid because of that. But at the end of the day here, I haven't seen why Tim's contribution is unreasonable, or what makes it so different from other contributions that have added functionality to the code base. I'm trying to guess here at what it might be and haven't stumbled on anything I can point to. Really, why is it so unacceptable? Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Seawind
Taking a break from the serious stuff ... or rather, switching over to the serious stuff... :-) This afternoon the winds were almost nothing, so I walked down to a nearby lake and flew my Seawind EP which is a radio controlled sea plane. The conditions couldn't have been more perfect and I had several nice flights, a couple touch and goes, and had fun just scooting around the lake up on step. If I can avoid crashing, it should be perfect for those warm summer evenings the hour or two right before it gets dark when everything calms down and the wind goes to zero ... Unfortunately I was the only one out there so I couldn't get any live action shots, but there is a promotional video I linked to so you can see about what it looks like in action. The ice is almost completely melted off the lake, but as you can see, we haven't started the spring green up yet. Chance of snow again tonight and tomorrow ... uf da as they say they say in these parts ... http://baron.flightgear.org/~curt/Models/Current/SeaWindEP/ Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] *** SPAM *** Re: Scene ambient and specularcolor changes
On Fri, Apr 3, 2009 at 7:26 AM, Vivian Meazza wrote: 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 been touched for ages). IMO, without any real data to judge it by, the specular adjustment is good enough. Ambient is still significantly too dark - on the side of an ac lit only by ambient light, it is just about black. In my experience, on the brightest days when the difference between ambient and diffuse is greatest, there is always enough ambient light to penetrate even the most intense shadows. I'll do a couple of screen shots later One thing to possibly consider is that when we (someday) get back to having shadows cast by the aircraft, we may need to recalibrate some of these parameters. I recall long ago when I was trying to play with ambient/diffuse parameters for terrain, I quickly discovered a big part of the problem is the lack of dynamic range of a computer monitor. The diffuse lighting is based on the angle of the surface relative to the angle of the light source, and near dawn/dusk this gets really low. And because of the way opengl does the lighting math you can't really do anything about that (nor would you want to.) However, in order to get the scene brightness back up to something usable, you have to boost the ambient component of the lighting artificially high, and then all shadows go away. Contributing to the problem (I think) is that most of us view the scene in a normally lit room. If we forced everyone to only view FlightGear inside a perfectly dark room, I think we could do a little better. But this is a really hard problem. Very easy to get wrong, impossible to get right, very hard to get mostly right (or not distractingly wrong.) Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] read sideslip data during replay
I haven't looked carefully at how alpha and beta are dealt with ... perhaps they are computed on the fly from other values and that computation overrides anything you might load from an external file? One possible way around this would be create a copy of the HUD configuration, modify the property name it uses to read beta from the standard name to something you create. Then when you load your data file back in for replay, fill in that new property name rather than the standard one, and your version of the HUD should respond appropriately. Perhaps there would also be some way to override the overridden beta value with a nasal script and then you'd be trading nasal work for HUD work. Regards, Curt. On Tue, Mar 31, 2009 at 8:40 PM, John Waget jwa...@gmail.com wrote: Hi all, I am new to flightgear so please help me out with this. I want to display the side slip data on the Hud during the replay process. During the replay process, fgfs simply read the input file we specified. However, I found out fg won't read the sideslip data from the file, so what should I do to force the fg read the sideslip data?? Thanks, John -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Fwd: Remove right access to CVS FlightGear/data
Referencing the attached email from Gerard Robin who has a number of his aircraft included in FlightGear CVS. He has indicated to me that he is no longer interested in maintaining the CVS versions of these aircraft. This puts us on an awkward position. Should we leave these aircraft in CVS as unmaintained entities that will accumulate cruftiness and work less and less well as FlightGear development goes forward? Do we find someone to monitor updates on Gerard's web page and try to keep these aircraft up to date in CVS ourselves (assuming his license terms allow that?) Do we remove the aircraft entirely from CVS? Do we wait and see if Gerard changes his mind again next week? Regards, Curt. -- Forwarded message -- From: gerard robin ghma...@gmail.com Date: Thu, Mar 26, 2009 at 5:42 AM Subject: Remove right access to CVS FlightGear/data To: curtol...@gmail.com Hi Curt, You probably noticed that i have stopped to update on CVS data, every model that i am working on. [snipped out the reasons why, but judging from the original CC list, this arises from an ongoing feud with a single FlightGear developer ... this is my (Curt Olson's) interpretation. Gerard can discuss those reasons on the list of he chooses to.] Consequently, for the health of the community, in order to avoid any noise, at least coming from me, i whitdraw from any official contribution . I will continue to work , with FlightGear like i did in the past, for friends , and for me. I know that i am not alone within that external FlightGear community. I ever offered to people who like it, my work. To conclude, could you remove my right access to CVS FlightGear/data ? I guess that this would be better for the security of FlightGear. Thanks for your work. Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Looking for FlightGear developers who may be interested in considering paid FlightGear consulting jobs
In the wake of Microsoft shutting down their flight sim operations, I have seen a significant up-tick in FlightGear inquiries and requests for help. Several companies that previously delivered Microsoft based simulation products have approached me with interest in migrating or interfacing their products to FlightGear. At least a couple of these organizations are ready to pay for some consulting time to help move their projects forward. The level of interest I am seeing is well beyond what I can handle personally. There is real interest, real need, and real opportunity here. It would be a shame to ignore it. I am proposing the idea of organizing a formal group of FlightGear developers who (a) have an interest in doing periodic consulting work, (b) have (or in the future may have) available time to devote to consulting work, and (c) have some knowledge and experience with FlightGear. FlightGear skills could range from knowledge of internal structures, knowledge of communication and interfacing, ability to do custom installation and configuration of FlightGear, 3D aircraft and airport modeling, 2D graphics, hardware design and interfacing, flight dynamics, flight control, etc. As we all know, the skill set that goes into a project like FlightGear covers an immense range and no single person can know or do it all. This FlightGear consulting group would be formed underneath the umbrella of Airborne Technologies, Inc. Several years ago I met the president of Airborne Technologies (ATI), became involved with one of their UAS projects, and I have now have become a part of the company. ATI is an established business in Alaska and has a long history with aviation and technology. We are involved with a number of projects that share common base technologies that include both hardware and software development for remote sensing type work. By acting as a central business entity, ATI would coordinate and offer structure and consistency surrounding FlightGear consulting activities. An established business presence is able to attract and leverage projects by adding value through hardware development, project coordination, training, and project support. The types of needs and requests I am starting to see have proved to be difficult to address with FlightGear's current informal support structure. Organizations can have needs that go far beyond a few mailing list questions, and they are willing to pay appropriate compensation to the right person for assistance. The proposed structured and professional approach will bode well, I believe, for FlightGear development and could potentially offer a substantial amount of paid work for interested developers. The purpose of this email is to gauge developer interest and start the ball rolling. Adding your name to our list of potentially interested developers does not lock you into working only through ATI exclusively. There's no problem if individuals and companies currently or in the future wish to make their own private arrangements. But I think it is important that we move quickly to gather a list of interested developers so we can try to address several immediate needs and be better positioned to provide paid support needs in the future. If you think you might be able to make some time in your schedule once in a while for a paid consulting job and have any of the range of FlightGear skills, I would love to hear from you. Even if you aren't available today and just have a few questions, I'd love to hear from you! Thanks!!! Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Help: Building a binary IO driver based on Altas driver
. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
On Sat, Mar 21, 2009 at 12:06 PM, Tim Moore wrote: Melchior FRANZ wrote: * Tim Moore -- Saturday 21 March 2009: Gene Buckle wrote: What benefit does the compound property offer? More concise syntax for aggregate values like colors, rotations, etc. Doesn't sound like a valid reason to me: SGVec3 vec = n-getVec3Value(/some/vector); The syntax is actually: Vec3d vec = n-getValueVec3d() vs. SGVec3 vec = getVec3(n-getNode(/some/vector, true)); That is not correct, because there is no explicit ordering of property node children. You need different functions, or some helper argument, for every property type that is vector-like -- colors, positions, normals, rotations, etc. I may be misunderstanding your point, but there are multiple children of a property node, all with the same name, then there is an explicit ordering ... you can provide the ordering yourself, i.e value n=2 in the xml file, or value[2] when referencing the property name, or getChild(value, 2) when using the tree walking API. And if you don't specify any ordering, the values are created in sequential order. If you have unique property names, then I don't see a need for ordering since you just reference the name of the thing you need. But in any case, I'm not worried so much about concise syntax in C++; I'm talking about the syntax of the XML files that will use the new properties. Again, I think that the syntax in the xml file is the least concern. Do your expected usage cases involve 100's or 1000's of these entities where a few bytes here or there could make a noticeable difference, or just a few here or there where we are talking about fractions of a percentage of the overall fiile size? Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
On Fri, Mar 20, 2009 at 10:22 AM, Stuart Buchanan wrote: Melchior FRANZ wrote: This will probably become a flame-war, but I see no way to avoid it. I think you laid out your position in a very well thought out and fair manner, backed up with many reasonable points and/or questions. If the replies to this thread have a similar tone and include any thought and insight, we shouldn't have a problem. :-) I can imagine an alternate perspective so I'm looking forward to hearing that too. Tim plans to extend the property system with compound data types, such as VEC3, VEC4, or COLOR. We've discussed this three times in IRC, and I've always pointed out why this is IMHO a *BAD* thing, and why I strongly object. But now he has implemented it in his source, and made that the base of further (desirable!) features. I don't want a flame war with Tim, but this needs to be decided *now*. Otherwise we might end up having to decide whether we want the (IMHO) evil property change *and* the nice features, or neither. And that's not how a decision about one of our foundations should be made! (To Tim's defense, he had planned to write an RFC to the devel list about it, though he also intended to commit parts of the change before that. And to my defense: I have told him that if he doesn't write the RFC *soon*, then I will bring it up on the list!) I think it would be good for Tim to explain why more complex types are required, as I'm sure he will do shortly :) Our current property system seems to match up well with C's view of data types. As Melchior points out, we have always represented records/structs as a subtree of properties hanging off a node. Arrays have been represented using numbered nodes as in ... pos/vec[0], pos/vec[1], pos/vec[2] or pos vec1.1/vec vec0.5/vec vec-0.2/vec pos or more verbosely: pos vec n=01.1/vec vec n=10.5/vec vec n=2-0.2/vec pos The main argument I can anticipate for adhoc aggregate types would perhaps be some sort of performance/space argument. If you want to store and retrieve a boatload of vectors in the property system, having a child node for each array element of each vector consumes extra space, and you burn extra time accessing the individual elements. And an aggregate type could be setup to have a better direct mapping to the required OSG/OpenGL form of the data which would eliminate the need to convert the value each time it is accessed. But as Melchior points out, doing this sort of thing could open up a big can of worms, and if space and access time is a key consideration, then is the property system the best place for that sort of data? If we start doing aggregate types, do we jump in with an adhoc approach and create a few things here and a few things there as needed? This seems to me to have the potential to explode in to a mess of accessor fuctions and near-duplicate code that would be required for each new type or variant. Perhaps *if* we want to extend the supported property types, we should think *very* carefully about the overall design of the property system. Do we add support for arrays? Could that be done in a reasonable manner, and could that be leveraged for Tim's needs? Most of the key opengl data types are things like float or int arrays. My immediate thought is that one could write some fairly straightforward code to interpret a given property node with 3 child values as a Vec3. Could we subvert the property attributes to indicate that a given nodes contains a Vect3. That way internal code could interpret it as a Vec3, while external interfaces would be preserved. I like this approach. We could easily write some helper functions that would deal with aggregate types at a higher level. Internally, they are still represented with the current property system, but a helper function could collect all the children values of a node and present them as an array of floats for instance. This would have a time/space overhead, but again, if that's a problem, then that might be a sign that the property system isn't the best place to store that data. Like Erik, I'm very concerned about making the external interfaces more complex. One of the huge strengths of the property system at present is its simplicity, and I think that would be lost. If we do move towards aggregate types, would we take a more object oriented approach to data representation? It would be nice to have the flexibility to then represent arbitrary collections of data like a C++ class. But if we do that, we really should support the concept of inheritant, and what about attaching functionality/classes to the data. But I'd still be interested in hearing Tim's perspective so I don't have to guess at what that might be. :-) Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Apps built with the Adobe(R) Flex(R) framework
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
2009/3/20 Mathias Fröhlich wrote:
Ok.
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. Given that, you might consequently want to
reflect
more complex types by the properties.
The aggregate types are all constructed as combinations of our simpler
types. I think what I would propose is we could add an API layer which
could read or write a node as an aggregate type, but internally it would map
these complex types to a parent node with several children. So our current
xml tools and property tree manipulation tools would all continue to work as
before, but an additional higher level function call would make the node and
it's children optionally appear as a more complicated aggregate type. For
instance, considure the following property tree entries:
/engines/engine[0]/rpm-history-arr/value[0] = 2200;
/engines/engine[0]/rpm-history-arr/value[0] = 2201;
/engines/engine[0]/rpm-history-arr/value[0] = 2201;
/engines/engine[0]/rpm-history-arr/value[0] = 2200;
.
.
.
/engines/engine[0]/rpm-history-arr/value[999] = 2198;
We could access this with a new convenience aggregate accessor (untested)
:-) The accessor functions would use some simple conventions to assemble
and return an aggregate structure based on the simpler property tree
represenation:
vectordouble rpm =
fgGetDoubleVector(/engines/engine[0]/rpm-history-arr);
vectordouble rps;
for ( unsigned int i = 0; i x.size(); i++ ) {
rps[i] = rpm[i] / 60.0;
}
fgSetDoubleVector( rps );
In this case, fgGetDoubleVector() would traverse the
/engines/engine[0]/rpm-history-arr parent node and find any children called
value. It would take their individual values and copy them into a
vectordouble and return that to the calling layer.
Similarly, fgSetDoubleVector() would traverse the provided vectordouble
and write each subsequent value as a child called value[n] underneath the
specifed node.
Because we haven't changed the property system, this same example could also
be written using the current API like this (untested pseudo code):
rpm_node = fgGetNode(/engines/engine[0]/rpm-history-arr);
rps_node = fgGetNode(/engines/engine[0]/rps-history-arr);
unsigned int size = rpm_node.num_children();
for ( unsigned int i = 0; i size; i++ ) {
tmp = rpm_node.get_child(i).getDoubleValue();
rps_node.get_child(i).setDoubleValue( tmp / 60.0 );
}
Nothing in the core/underlying property system would need to change, we
could just add some additional convenience functions that would map more
complex structures back and forth to a traditional property tree
representation. It's nothing that individual functions couldn't already do
themselves, so I don't see a problem with adding some additional API calls
if this is a convenience that could be used throughout the application.
My only additional comment is that if this approach is objectionable due to
performance or space considerations, then perhaps the property tree is not
the best place to be storing this data in the first place.
Regards,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
On Fri, Mar 20, 2009 at 6:51 PM, Tim Moore timo...@redhat.com wrote:
Gene Buckle wrote:
In my opinion this planned change would be an incredibly bad
move, and would almost have to be seen as the destruction of
the property system. So let me repeat: I strongly object.
I guess it boils down to whether or not the benefit gained outweighs the
down side.
What benefit does the compound property offer?
g.
More concise syntax for aggregate values like colors, rotations, etc.
To me the idea of giving nasal efficient access to vec3 and vec4 types for
manipulating things like material properties, texture coordinates, lighting,
and positions seems like the strongest argument for this proposal.
Reading back through Melchior's original email, perhaps the thing that might
concern me the most is what happens if we use some random xml tool to read
in a flightgear xml file, make some manipulation (not necessarily touching
the proposed new vec3/vec4 types) and the write it back out. Will this
proposed xml format allow this to happen without the random tool corrupting
all the vec3/vec4 entries because it didn't know how to properly deal with
them? What ever we do, I think it's important to have our xml play nice
with others. (if a vec3 is interpreted as a string by some other tool and
written out verbatim, that's fine, but if only the first value is
interpreted as a number, and that's all that is written back out, it would
be an easy and subtle way to corrupt a flightgear config file.) What other
xml tools would read/write our files anyway? I don't necessarily know, but
maybe an external modeler or a plugin to an external modeler that doesn't
know about our new data types?
JSBSim has a way to input tables and vectors I believe as a single xml
entry. (The numbers are separated by spaces.) Perhaps we should take a
peek at how they do things there and what potential implications that has or
problems it might or might not cause? Maybe there is some existing
precedence here we can consider.
On the flip side, (just my impression), arguing for this change because the
alternative is a more verbose xml syntax is maybe the weakest argument. xml
is already pretty verbose and a percentage difference in verbosity isn't
much of a big deal I don't think.
Melchior originally wrote:
What is it about: Currently, if we have data in the tree that belong
together, this is done via subnodes under a common property, e.g.:
color/
|__red (float)
|__green (float)
|__blue (float)
just like it's done in C or C++:
struct color {
float red;
float green;
float blue;
};
For the types that Tim proposes, they are almost always written as float
color[4] and accessed with color[0], color[1], color[2], color[3], or
pos[0], pos[1], pos[2], etc. in C and C++ when you are dealing with OpenGL.
Anyone who would represent an opengl color in C/C++ the way Melchior
suggests would have to convert it to a vec3/vec4 before actually using it.
Tim, rather than doing specific vec3 and vec4 data types, would it make
sense to have a generic array data type ... perhaps that can be
float/double/int depending on the get/set methods used? But then it would
be really nice to use the vector type out of the STL instead of raw arrays
... and then it doesn't match up as well with native opengl types.
Regards,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] hypothetical gpl question
On Tue, Mar 17, 2009 at 5:23 AM, Jon S. Berndt wrote: There are some things we need to know that aren’t described below. Was the FlightGear source modified? If not, then they would be distributing an existing FlightGear that anyone can download. All they need do is mention where FlightGear source can be obtained. If they have modified source code to FlightGear, then they should make the source code available (if requested) to anyone who asks. That doesn’t mean anyone would want it. I also would not have a problem with source code to a demo NOT being released if the intent was to keep (at this time) potentially dysfunctional code from escaping into the wild, as long as the eventual production code was made available, if requested, and if potential customers were made aware of that right to the source code. You’ve got to ask, really, is FlightGear made to be used or not? Is a usage good for the long term, or not? How persnickety do you really want to get? As we’ve discussed before, money is not the issue, but whether the customer is aware of the fact that the source code is available (and perhaps that the program can be downloaded freely from the FlightGear web site). Is FlightGear GPL or LGPL? FlightGear is GPL. FlightGear is of course made to be used. In the hypothetical situation I am describing, I have not had any hypothetical contact with the hypothetically alleged GPL infringer so I have very little information to go on (hypothetically.) The consensus is that only distributing a demo or free copy of a modified binary does not exempt someone from honoring the terms of the GPL. That makes perfect sense and it's good to cut away that potential distraction. It is also good to be reminded that distributing a modified binary isn't necessarily a violation in and of itself. The violation would technically happen when someone who received the modified binary asked for the modified source code and was refused. Here's a question: Does a 3rd party have the right to ask for the modified source code, even if none of the entities receiving the modified program don't care to ask for the source code? I appreciate all the feedback. Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] ac3d and materials
On Mon, Mar 16, 2009 at 11:48 AM, Ron Jensen wrote: Shouldn't ambient color be set scene wide? From an artistic point of view I can see setting it on a per-material basis, but for a simulation environment that controls the direct lighting already it makes sense to give the ambient color over to the environment. Actually no. For each surface there are ambient, diffuse, specular, and emissive properties. These define the surface properties. For each light souce there are also ambient, diffuse, specular, and and emissive components. This defines the nature of the light that is cast on the surface. OpenGL combines the light source properties and the surface material properties to produce the actual visible color of the surface that is reflected back to the viewer. So it is correct to define the ambient, diffuse, specular, and emissive properties of the model surfaces. The environment defines the corresponding values for the light that illuminates the surface. OpenGl computes the correct color that is reflected back for each pixel. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] ac3d and materials
On Mon, Mar 16, 2009 at 2:16 PM, syd adams wrote: Im also in favor of this change I prefer to control the ambient property , myself. Let me also chip in that in a past simulation system I worked with, it was always highly annoying when a model looked good in the 3d modeler tool, but looked awful or just different once it was loaded up in the real time simulation. I think the more of these material settings we can support so that the model in the simulation looks just like the model in the 3d modeling tool, the better life will be. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] hypothetical gpl question
Here's a hypothetical question. Let's say some company A builds an internal product prototype that incorporates FlightGear as part of a larger aggregate system. Let's say they even make a few small changes to FlightGear. Now they give away a demo system to a couple different potential customers and say, Hey what do you think. They haven't rolled out an actual product, they haven't had any actual sales. No customer has paid any money for the copy of the system. Has the GPL been violated? Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal alternatives : possible, of course,
This thread has been quite entertaining! A big thanks to all the participants!!! :-) Curt. On Sat, Mar 14, 2009 at 8:33 AM, Jon S. Berndt jonsber...@comcast.netwrote: Oh, man -- giant Nasal flame war and I totally missed it. Melchior just now pointed me here. Sadly (or, well, not at all, actually) Andy's been doing a lot more of the daddy thing than the hacker thing recently. I kept up fairly well as a developer when we had two, but when we went from two to four kids in one fell swoop, it was like the rocket sled hitting the water trough. JB -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear licensing
Hi Norman, Yes, the intent has always been to release simgear under the terms of the LGPL. This is a good reminder of that. I'm on a short trip out of town and typing this from a very tiny keyboard, but this something we definitely need to clarify and bring into consistency. Good to here from you again! -- Curt On Mar 8, 2009 12:59 PM, Norman Vine n...@cape.com wrote: Hi all, While I was in the process of perusing the SimGear code I noticed that some of the newer code was being released under the GPL As part of the original SimGear team I was under the impression that SimGear was specifically LGPL as expressed here http://simgear.org/mission_statement and here http://cvs.flightgear.org/viewvc/SimGear/COPYING?revision=1.1.1.1root=SimGear I have not been an active member of the FGFS community for a while and realize that things 'change' but I am curious The last thing I want todo is start anything even resembling a 'license' flame. but ... I find this unfortunate and a bit confusing ... Norman -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal alternatives : possible, of course, but trivial or hair pulling task ?
On Fri, Feb 27, 2009 at 4:27 AM, Melchior FRANZ wrote: Adding another language wouldn't be that hard. Actually, we had another one before nasal and beside nasal for a while. It was called PSL (plib scripting language), and we ripped it out because Nasal was/is just better and because offering and maintaining two languages it utterly pointless . And that's why I consider the likeliness of getting lua or any other language support committed approximately zero. I for one would strongly oppose (veto-style :-). Of course, what you do in your private copy or fork is your business. Let me jump in with some pre-coffee comments (so I'm not yet responsible for anything I say) :-) Nasal is *very* well designed, compact, and efficient. It is used heavily throughout many areas of FlightGear. So I can't imagine any scenario where we would switch to some new scripting language unless a lot key developers were convinced that it was every so much better that that benefit would substantially outweigh the cost. And I find that scenario hard to imagine. I agree that if you want to play around with integrating Lua into your own development tree, that's great. You will learn a ton about flightgear and it's internal structures in the process. I tend to side with others that there would need to be some overwhelmingly compelling reason to support lua along side Nasal within FlightGear. If the primary motivation is language preference, that is going to be a really tough sell around here ... and that is because Nasal is *really* slick, brilliantly conceived, well implemented, and it has served us so well. But all that said, FlightGear is intended to be a developers sandbox, so please feel welcome to play and learn and ask questions. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Looking for a volunteer (Fwd: open source software at openDesktop.org)
Hi, I just received this email this morning. Do we have anyone who would be willing to sign up at this site, register our project, and then maintain the information over time as we make new releases? Thanks! Curt. -- Forwarded message -- From: Frank Karlitschek fr...@o---d--.org Date: Thu, Feb 26, 2009 at 4:01 AM Subject: open source software at openDesktop.org To: Frank Karlitschek fr...@o---d--.org Hi, I saw that you are a free software developer. I´m also a free software supporter and I´m running the openDesktop.org websites including KDE-Look.org, GNOME-Look.org, Qt-Apps.org, GTK-Apps.org, CLI-Apps.org and more. The sites are application directories but also communities where developers can get in contact with users. Users can rate and comment your software, become fans, ask questions in the knowledge base system, look at screenshots and download your software of course. We support OpenID and everything is free of course. We already have millions of visitors and over 100.000 free software uploads. www.openDesktop.org I just wanted to ask you if you might consider to register at openDesktop.org and upload your software. So you and your software can become part of the community. Sorry for bothering you. If you have any questions please send me an email so I can help you. Cheers Frank Frank Karlitschek fr...@opendesktop.org -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear FAQ?
Hi, Do we still have someone maintaining the FlightGear FAQ? Someone pointed out a dead link, and I could patch the version on the web site, but it would be nice to also fix this in the upstream source. Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] telemaster model
On Tue, Feb 24, 2009 at 6:14 AM, cullam Bruce-Lockhart wrote: Hi there. I was going to do some work on modeling a Senior Telemaster in Matt Lab, but a friend told me that he thought someone had already worked on that. Does anyone know if there is already a model for a Telemaster out there, and if it's available? Thanks a bunch. I'm not aware of a Senior Telemaster model in FlightGear, but we do have a model for a Sig Rascal 110 which is roughly in the same size category (although a little slicker and faster.) The Rascal model might server as a starting point if you wanted to work on modeling the Senior Telemaster. I have a Senior Telemaster here I use for UAS work. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property System Overview?
On Sun, Feb 22, 2009 at 3:38 AM, Erik Hofman e...@ehofman.com wrote: The main reason for implementing the property system is that it can represent the contents of any XML file in memory quite easily. I appreciate everyone's response to my questions about describing FlightGear's property system. I've pulled bits and pieces together from just about everyone's comments. Thanks! Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Property System Overview?
Do we have any documentation or overview of the property system that gives a high level view. I found something about the contents of the property tree on our wiki. There's probably some api documentation floating around. But what I really would like is a higher level description of what the property system is, why it's useful our application, etc. Pretend Curt is in a meeting and he's given 30 seconds to explain the property system to smart people who have never seen this concept before. I've just burned my first 15 seconds with U, er, It's like , you know Now all these smart people are scowling. Now what!?! Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] gps?
Now that you've explained what ecrit means and I'm sure everyone is pleased to find out it's nothing painful, :-) I don't think you necessarily need to worry about changing your email client. Regards, Curt. On Tue, Feb 17, 2009 at 2:47 PM, Sébastien MARQUE wrote: sorry guys for that, I forgot to withdraw the accent, btw I haven't found yet where I can change this permanently in my thunderbird config. seb Csaba Halász a ecrit (wrote): On Tue, Feb 17, 2009 at 9:14 PM, syd adams adams@gmail.com wrote: I have a silly , non FG question what does syd adams a écrit : mean Googling didn't help , and I don't speak french Well, look at the header for the quote above, and try to compare with the ecrit thing :) -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] gps?
At one point I think I recall that we had a variant of the C172 with a working GPS installed in the instrument panel. I don't see that any more now. Does anyone recall if we had such a thing and know where it can be found? Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] wildfire ?
On Sat, Feb 14, 2009 at 12:44 PM, gerard robin wrote: Sure that is usual with MSFS Games, anyhow in the aircraft Company i don't remember simulators with such wildfire ( when the student pilot crash ) . Has it changed ?. Who said, here, that FG is NOT a GAME ? :) :) :) For what it's worth, the USFS (US Forest Service) at least in one location has invested heavily in a networked group of flight simulators used to practice water bombing procedures, communication, techniques, etc. They currently are not using Flightgear for this purpose. However, here is an example of how this features is used to train real pilots doing a critical job and hopefully helping to save lives. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: data/Aircraft/F-8E-Crusader Crusader-SetBase.xml, 1.23, 1.24
No I agree, we shouldn't be mixing policy and capability up like this. These things should be set at an application level according to individual user preference, it always turns into a big mess when an aircraft author tries to change global settings from within an aircraft. It also leads to support problems if this changes a users default and they wonder why wild fire isn't working any more. Gerard, why don't you just turn wild fire off for yourself globally, rather than sneaking a hidden application bomb into your aircraft? Regards, Curt. On Sat, Feb 14, 2009 at 1:49 PM, Melchior FRANZ mfr...@aon.at wrote: * Gerard Robin -- Saturday 14 February 2009: Log Message: withdraw the game coat + environment + wildfire + fire-on-crash type=bool false/fire-on-crash + /wildfire + /environment AIRCRAFT MUST *NOT* CHANGE SYSTEM SETTING! This setting disqualifies the F8 for inclusion in a release. Oh, well. Why do I always have to complain?! Maybe everyone else doesn't care about cleanliness and a sane concept, anyway. Sigh ... m. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: data/Aircraft/F-8E-Crusader
On Sat, Feb 14, 2009 at 2:12 PM, Martin Spott martin.sp...@mgras.netwrote: Melchior FRANZ wrote: * Gerard Robin -- Saturday 14 February 2009: Log Message: withdraw the game coat + environment + wildfire + fire-on-crash type=bool false/fire-on-crash + /wildfire + /environment AIRCRAFT MUST *NOT* CHANGE SYSTEM SETTING! This setting disqualifies the F8 for inclusion in a release. Oh, well. Why do I always have to complain?! Maybe everyone else doesn't care about cleanliness and a sane concept, anyway. Sigh ... Well, you should realize that FlightGear still is (fortunately) not your private project. If this sort of 'gaming' setting is being forced upon users and/or aircraft developers, then you should not feel surprised if someone's going to work around it. This is not about a sane concept, this is simply a case of MF being totally agnostic about other people's experience and preferences. So, before using strong words, please consider opening your eyes, No I think Melchior is justified (as occasionally can be the case) :-) here. The aircraft config is the wrong place to put this sort of setting. An aircraft config file is the wrong place to set global application level settings. We could simply default wild fires to off in the preferences.xml file and that is perhaps the thing to do. What Gerard has done creates a very messy situation ... maybe not with just one instance. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: data/Aircraft/F-8E-Crusader
On Sat, Feb 14, 2009 at 2:16 PM, Martin Spott wrote: Curtis Olson wrote: No I agree, we shouldn't be mixing policy and capability up like this. Well, as long as the Flightgear development crowd fails at establishing procedures that, for example, allow to negotiate on 'moderate' system settings (or whatever is at stake), you can't expect people to subordinate the dictate of a very individual. The project should do it's homework first, Wild fires are a newly added feature to CVS, the table is wide open for discussion if anyone cares to discuss the issue. Let's not bring our pet peaves into the discussion, that only obfuscates the real issues. I sincerely hope that Gerard will revert this change and again, leave the choice of what application level features are enabled to the end user, not to the aircraft designer. If we want to have a discussion about defaulting wild fires off versus on, let's do that. That's the real issue that Gerard is attempting to address. And even if the result of the discussion is that wildfires are on by default, anyone who prefers otherwise can *easily* make that change locally at an application level. There's no need to add cruft to individual aircraft, that just creates a messy situation. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Curtis, From your interview UAS as virtual entity in multiplayer
On Wed, Feb 11, 2009 at 2:22 PM, Geopilot wrote: Just read your interview w\and was intrigued by this UAV. this copy of FlightGear (which is being driven by the life real world flight data) can be registered in the FlightGear multiplayer system, so now our real UAS is injected as a virtual entity into the multiplayer system so all the other flightgear pilots can see the real UAS. How would we see it on the servers? Hi George, If someone was collecting telemetry data from a real world aircraft (manned or unmanned) or a real world vehicle of any kind, and then passing that into FlightGear to create a slaved virtual view, and if that copy of FlightGear was registered with the multiplayer system (just like any other simulator pilot), then that real world vehicle would appear on our multiplayer server just like any other multiplayer entity, and in fact, no one else would really have any way of knowing if the entity was driven by real data, simulated data, or a replay of real data. (I hope that makes some sort of sense.) I'm not sure if there is a critical real world use of this sort of thing, but I think it's at least pretty cool. Now I think we have some sort of view manager feature where we can watch the sim relative to the location of some other AI/multiplayer entity, right? So theoretically, anyone could watch in FlightGear from the perspective of the real aircraft (if a real aircraft was driving a FlightGear session.) Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Q: OpenGL version requirement for FlightGear 1.9.1
On Fri, Feb 6, 2009 at 8:01 AM, David L. Page wrote: Michael, thanks. I am trying to run FG through a multi-display system using Chromium, which is an open source tool that replaces the OpenGL DLL to drive multiple displays without having to recompile FG. FG runs slowly with flickering and reports an error repeatedly about not finding glUseProgram. I suspect the repeated error reporting is causing the slow down and flickering. Also, I suspect that FG thinks it has OpenGL 2.0 support (thus the glUseProgram) when Chromium only supports upto 1.5. Anyway, if anyone has something definitive on FG's OpenGL min version requirements that would help. Hi David, Depending on what you are trying to accomplish, FlightGear also has built in functionality to drive multiple displays and multiple windows from a single instance (as of v1.9.0). Look for the docs-mini/README.multiscreen for instructions and examples. Also you can beat this up with hardware and use something like the matrox triple-head-to-go, but even with that, you really want to use FlightGear's capabilities to setup multiple cameras, 1 for each monitor, so you can configure the right separation between the screens to account for the display borders. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] VATSIM connectivity redux
this because we wouldn't necessarily need to change anything within the FlightGear source code, and we would automatically support current and past versions of FlightGear. There would need to be some dancing in terms of the FlightGear mutiplayer protocol. Certainly you could reimpliment a functional interface, but it might save you time if you could borrow some code from the FlightGear multiplayer server. That could only happen with express permission of the authors of that particular code. Some here may argue vigorously against this, but I think a lot of people would be pretty pragmatic about this ... assuming you had full support from the multiplayer server author(s) and it would be their decision to make. Otherwise you'd have to look at the protocol specification and rewrite your own FlightGear compatible interface which probably isn't horribly difficult, so maybe that would be the way to go and you wouldn't risk offending anyone. But if you do that you need to be pretty careful not to look at our multiplayer server code lest it be too tempting to copy from it. I do think it's worth pushing towards vatsim compatibility and I appreciate your persistence as we try to find a way through that satisfies all the different constraints. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear mentioned in The Register - MSFS Add-on makers looking elsewhere
On Tue, Feb 3, 2009 at 7:10 AM, LeeE l...@spatial.plus.com wrote: Most of the tools required are already built in to FG; it just lacks a suitable model animation development UI. FG obviously can load an animate the models, once in an acceptable format, so it's more a case of either adding an FG mode and a UI that doesn't require the simulation stuff or creating a model animation utility using the model handling code already in FG and adding an interface to it. Not a trivial job, in terms of time required, but all the model loading, visualisation presentation and animation code already exists. This might be a perfect time for someone to start assembling and developing a set of tools and instructions for migrating MSFS aircraft over to FlightGear. We still don't know for sure what MSFS will ultimately do, but if someone developed a way to ease the migration of MSFS aircraft over to FlightGear, I'm sure there would be a tremendous interest right now. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear mentioned in The Register - MSFS
On Tue, Feb 3, 2009 at 10:34 AM, Martin Spott wrote: Curtis Olson wrote: This might be a perfect time for someone to start assembling and developing a set of tools and instructions for migrating MSFS aircraft over to FlightGear. Let me have a little informal poll in this context: Do we still depend on a text-only file format for 3D models ? FlightGear supports any 3d model format that OSG has a loader/plugin for. There must be some sort of model conversion path from MSFS given the right set of tools. One thing that would be really cool is if someone could figure out the MSFS model animation scheme and write some sort of conversion utility or migration assistant to help with model animations. Cockpits might be another issue, and of course flight dynamics are an issue. So the process isn't trivial, but someone looking to do a quick migration test could plug in a similar dynamics model as a place holder until they can come back and do more detailed work on that front. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim sliding helicopters bug (+ ugly fix)
On Tue, Feb 3, 2009 at 10:50 AM, Jon S. Berndt wrote: * Jon S. Berndt -- Tuesday 03 February 2009: It's a tough problem, [...[ Maybe we should hire a rocket scientist? :-] m. With our *huge* budget? :-) I have noticed a measurable uptick in FlightGear interest since MS announced that they have laid off their entire simulator staff. I sincerely believe there is going to be more and more opportunities available for individual FlightGear consultants to help companies push forward with their FlightGear related projects. There have been a couple things over the past years that have come across my plate which I have snatched up. Recently there have been a few more things come through that I just don't have time for. In some cases I've tried to identify individual developers that I know have a matching skill set and contacted them directly. And in the case of this recent NASA project, when they had trouble finding a specific individual, I put a call out to the entire devel team list. Unfortunately (for us) with this NASA project I recently posted about, they found an internal person after one of their other projects was cut. But I'm sure there's a NASA employee that is current exhaling a big sigh of relief. :-) So I believe this subject is going to come up more and more often where any number of companies or research groups will determine that FlightGear is their best way forward and are willing to hire individual developers (probably as a temporary consultant, but maybe sometimes as full time employees) to fill in functionality gaps, fix bugs that are show stoppers to them, or interface with their existing software or hardware. I think 2009 will be a very exciting year for the FlightGear project. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear mentioned in The Register - MSFS
On Tue, Feb 3, 2009 at 10:50 AM, R. van Steenbergen wrote: I can say for one thing: The cockpits are pretty much a no-go. Most aircraft in FS9/FSX have gauges which consist of (platform and API-specific) code which make up the gauge graphics. Converting XML gauges from the Microsoft format may be entirely possible, but you can forget about using .GAU files (these are basically DLL's). In addition, most decent (payware) aircraft have modules which integrate with FS200x on a game engine level, to simulate anything from aircraft systems to world interaction. With the cancellation of the Flight Simulator franchise, however, developers may actually switch over to FlightGear for developing payware aircraft. This is where MSFS got big, the default stuff in MSFS isn't really that impressive but the number of add-ons you can get for the series is tremendous. But then again, GPL may be a threshold for proprietary developers. It is certainly true that any MSFS developer coming to look at FlightGear for the first time will have to learn and find a way to fit into an entirely new culture. I like analogies, so imagine someone switching from doing their email in outlook to doing their email in google (online.) There are major paradigm differences, and the person is going to start out a little bewildered, not be able to find how to do things in ways they expect, and be faced with a number of new features that don't make sense or don't seem to have any real use. But then as you push forward and figure things out more and more, you discover new ways to do things, you begin to forget about some of the old features you used to think were critical, and start critically depending on some of the new features you used to not understand or not care about. Some people will handle the transtiion better than others. I think there should be some weight on the incoming MSFS developers to investigate flightgear strutures and mechanism and do some of the work to develop tools to migrate their work into our way of doing things. It can't be a one-way street where FlightGear has to do all the work up front. It should be a partnership where we help build the bridge from our side, and they help build the bridge from their side, and we meet in the middle. And then once the bridge is connected, both sides get to enjoy the benefits of the other side. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear interview posted
I did an interview for a blogger named Diego Rodríguez last summer and it has just been posted. I may have been the only person to read it so far, but if anyone is interested, here it is: http://aerialphenomena.blogspot.com/2009/02/inside-flightgear.html Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main globals.cxx, 1.61, 1.62
On Fri, Jan 30, 2009 at 12:59 PM, Melchior FRANZ mfr...@aon.at wrote: * someone off list, but IMHO this should be discussed openly: [...] but the intent is for FG_ROOT to point to a top level directory (i.e. the root) and beneath that would be bin/ data/ src/ lib/ include/ etc Wow, I'm sorry if I caught you on a bad day. I can't deal with a big flame war this afternoon, maybe we can find a way to discuss this issue in less apocalyptic terms? There's only one reason why we need to point fgfs and associated scripts and tools to some place *at all* (using FG_ROOT or --fg-root): So that they can find the data at runtime. There's no reason *whatsoever* to have a pointer to source files and #includes. Structurally, my view of root is that it should point to the top of a relocatable tree. A design goal of flightgear has always been to keep itself contained in one area and be a good citizen of your hard drive. So in my view, the root directory would contain things like the binaries subdir, the data subdir, the scenery subdir, possibly external aircraft subdir, and possibly the source code that corresponds to this version. A person could have several FG_ROOT's on their hard drive corresponding to a stable version, a development version, or some other version (perhaps a version that talks to some other software you need.) Recall that we don't require (and actually recommend against) putting add on scenery inside the data tree. And the runtime data directory is that which contains file version. It's *not* a directory which contains a data/ directory which contains the data. Making the layout optional was a bad idea 10 years ago, and it is a bad idea today. Even worse, as we have many more users and it bites us a lot more often in the ass than it used to. Despite the name calling, it is inconsistency that bites us. My intention is to remove the disgusting hack that checks for an existing data/ dir and that appends it if found, and that before the 2.0 release. IMHO, this is moving in the wrong direction to fix the inconsistency. I'm not an archeologist, and I don't think we should look at what seemed to make sense a decade ago. What we have now doesn't make sense. It leads to bugs and confusion, while not having a *single* advantage. Or could anyone tell me one, please? Just one? I think I already explained my thoughts in terms of logical consistency, but I'm sure you are asking for a reason you like, so I won't even attempt that. :-) Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main globals.cxx, 1.61, 1.62
is also not good (I feel.) What probably needs to happen is a bit more open discussion, and then someone is going to have to dive in and do some hard work to fix it in a way that make logical sense (is consistent) but that doesn't make too many policy and file system layout assumptions. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] weird memory bloat
On Wed, Jan 28, 2009 at 11:31 AM, John Denker wrote: On 01/28/2009 10:20 AM, Tim Moore wrote: Alternatively, try starting with /sim/rendering/random-vegetation set to false. Bingo. That makes a huge difference. VIRT = 371 instead of 888. I imagine there are a lot of trees around KASE... Yes. Hey Tim, If you are in poking around the random tree code, here's something else I noticed. The original OSG implementation had a nice feature where it phased in tree'd areas little by little ... so as you approached an area, you might see one or two trees at some medium distance, and as you flew closer, more and more trees filled in the spaces in between until you got to full coverage when you were close to an area. This was subtle enough that often you didn't even notice the trees being added and removed as you flew. Lately, with some of the tree related patches and changes, I'm seeing whole blocks of trees pop in and out at once, which does lead to a distracting popping effect. I really liked the old subtle way of blending in trees one bit by bit as you got closer. It seems like it's only half broke at the moment, sometimes I see both happening in different areas of the scenery. Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug report: Tile loading problem?
Hi Rob, It appears that the code that computes how many rings of tiles to load is perhaps not doing that correctly any more? Originally the code would ensure that enough tiles were loaded to cover the visibility range so that the end of the world would blend seamlessly into the fox color which matched the base of the sky color and you didn't see these artifacts. Regards, Curt. On Tue, Jan 27, 2009 at 6:50 AM, Rob Shearman, Jr. wrote: Hello -- Cruising at FL300 yesterday, and FL310 today, in the Citation-Bravo, I notice what looks like a scenery tile loading problem (see the so-named screenshots below, and notice the white areas near the horizon). However, cruising along, I expected to steadily get closer to the edge of the tile shown there, and eventually see the next one pop into place -- but it seemed more like the edges were not moving, even though the cloud cover texture (and presumably the ground below) were scrolling past at a reasonable rate. This is using Fred's Win32 build from 2009-01-11, and data from same date. 3D clouds NOT enabled, and METAR as shown in the third shot. http://s289.photobucket.com/albums/ll209/rmsjr1974/?action=viewcurrent=tile-loading-prob-1.jpg http://s289.photobucket.com/albums/ll209/rmsjr1974/?action=viewcurrent=tile-loading-prob-2.jpg http://s289.photobucket.com/albums/ll209/rmsjr1974/?action=viewcurrent=tile-loading-prob-3.jpg Ground speed was something like 340-350 knots, if that matters to anyone. Cheers, -R. Robert M. Shearman, Jr. Transit Operations Supervisor, University of Maryland Department of Transportation also known as rm...@umd.edu -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Interesting FlightGear Job Opportunity (NASA Ames)
Hi, I am posting this on behalf of Glenn Meyer @ NASA Ames who is looking to find a skilled FlightGear developer for a 4-6 month full time contracting opportunity. I believe there is some flexibility with how the arrangements could be setup, so if you think you might be interested and have some availability, and if you think you have some of the requested skill set, please feel free to contact Glenn. (Glenn's contact info is at the end of this message.) Job Description: Four-month contract, full-time plus, integrating simulation testbed with proprietary and OpenSource simulation systems. Responsibilities will include: Helping integrate a multisystem UNIX- and Linux-based flight simulator application with FlightGear, OpenSceneGraph and proprietary cockpit instruments and software. Intimately understanding, integrating and sometimes modifying FlightGear and OpenSceneGraph to interface with an in-house simulator application. IPC, graphics, general application, and possibly real-time programming will be involved. Experience: Minimum 5 years, ideally 7-10 years of C/C++ programming experience with 5+ years Linux/UNIX experience. Must have -- experience with FlightGear development and FlightGear internals. Experience with OpenGL and Linux/UNIX-based 3D APIs such as OpenSceneGraph and Performer is preferred. Experience with shared memory and sockets programming is required. This is a senior level applications development role. X Glenn Meyer Principal Engineer office: (650)604-1491 or -3281 PerotSystems fax:(650)604-3729 NASA Ames Research Center (MS 262-4) grmeyer at mail.arc.nasa.gov grme...@mail.arc.nasa.gov Moffett Field, CA 94035-1000 X -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] v1.9 screenshots
I've updated the FlightGear.org web site with v1.9 screen shots. These are all from 2 people so if anyone else has anything nice to add (or possibly replace existing images with something better) please feel free to send me links to the pictures. Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Microsoft Shuts Down 'Flight Simulator' Game Studio
On Sat, Jan 24, 2009 at 8:16 AM, Jon S. Berndt wrote: GWMobile wrote: I just want to thank everyone here for the time and passion they've poured into Flight Sim for so many years, and to let you all know that every person at ACES is in awe of how much the community cares about what we build. It seems unlikely that Flight Simulator will go away entirely, even if it means branding a Live game with the name, fans speculated. A version of this post originally appeared on AppScout . I think the closure of ACES is so sad on so many fronts. It doesn't seem to make any sense, either. I think it's too early to say how this will affect FlightGear other than we are being mentioned among the remaining players in the market. Also, I don't believe MSFS will simply end, but it remains to be seen in what form it re-emerges and where and how. That said, we should be prepared for a lot of new folks at least coming and taking a quick look at what we are doing over here, so when new faces show up, please be welcoming and patient with them! Some might even know a few things about flight sim development but not be familiar with our culture, so again, let's be patient and welcoming. FlightGear should be a place that welcomes new thought and new ideas and new faces that are certain to stretch and expand our culture. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 33, Issue 26
On Sat, Jan 24, 2009 at 12:14 PM, Martin Spott martin.sp...@mgras.netwrote: gerard robin wrote: On samedi 24 janvier 2009, BARANGER Emmanuel wrote: I am tired of the negative attitudes of some. Have some rest :) :):) You don't do anyone a favour by belitteling Emmanuel's statement. I propose you'd better think about it, Hey guys, my 4 7 year old girls are running around the house today with not enough sleep acting this same way. Please do not make me have to police two places at once. :-) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] airliner ditching miracle ... or not
Well, my point was that just the part about having to sit in the water (not considering the impact) would still be ugly. Curt. On Fri, Jan 23, 2009 at 11:57 AM, Josh Babcock jbabc...@atlantech.netwrote: Curtis Olson wrote: if we had to ditch the ship out there, it could have been really ugly ... Yeah, I hear a water landing in a ship is pretty hard. Better than a runway landing in a ship though :) Josh -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] R.I.P. MSFS?
On Fri, Jan 23, 2009 at 12:29 PM, Melchior FRANZ wrote: http://www.gamasutra.com/php-bin/news_index.php?story=21981 http://www.steve-lacey.com/blogarchives/2009/01/the_end_of_an_e.shtml I would emphasize the question mark for the moment. This wouldn't be the first report of the demise of MSFS that I've heard over the years. I can't imagine they would just axe it, It would make sense that they could at least sell that division and get something for it. Let's keep our eyes open on ebay for flight simulator companies for sale. :-) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Resizable dialog boxes
Hi Melchior, The resizable dialog boxes are very nice! Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Garmin 400
I'm excited! I just got FlightGear connected up to a Garmin 400 which speaks the same protocol as the 430/530. I haven't looked at sending over fuel and radio information, but all the positional / velocity stuff is working. I'm going to do some more testing here before committing the new protocol. GPS training is a *huge* thing that people want to do these days with flight simulators. (Oh and sorry for the small fire I started in the middle of KSFO when I hit the VOR shack.) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Garmin 400
On Mon, Jan 19, 2009 at 3:06 PM, Martin Spott wrote: Hi Curt, Curtis Olson wrote: I'm excited! I just got FlightGear connected up to a Garmin 400 which speaks the same protocol as the 430/530. I haven't looked at sending over fuel and radio information, but all the positional / velocity stuff is working. I'm going to do some more testing here before committing the new protocol. In which sense is this different from the I/O protocol you enable via the --garmin=[...] switch ? The --garmin= protocol outputs basic NMEA strings with some (a) garmin extension. What I am implementing is the ARNAV format which I've also heard called the AV400 format or RS-232 Type 1. There is a set of messages that the Garmin 295/296/400/430/530/etc. emit. I previously implmented this message set which you can activate with the --AV400=[...] option. This works for driving a Garmin 295/296 gps. However, the 400/430/530 gps expect a different command set from the simulator which is what I have implemented. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Garmin 400
On Mon, Jan 19, 2009 at 2:53 PM, Torsten Dreyer wrote: Will you also commit the Garmin 400, so everybody can download one? Alas, I haven't yet figured out how to commit physical hardware to CVS ... maybe with GIT? I can commit the protocol updates soon though. :-) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Garmin 400
On Mon, Jan 19, 2009 at 3:56 PM, Martin Spott wrote: This sounds great to me. Even though I would not count the GNS430/530 as being among my personal favourites, I know they are _very_ popular and I've been using such thing at least in two different aircraft. If I'm not mistaken, this would probably allow FlightGear to drive the Windows-based series 400 simulation software - buying a real GNS430 just as an add on might be somewhat expensive for the casual user :-) It would be great if it was possible to drive the windows based 400-series simulator software, but I don't have any idea if it's setup to respond to serial input. My understanding is that it had a graphics front end combined with a backend engine that communicated via network packets. But I could be wrong. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] airliner ditching miracle ... or not
On Sun, Jan 18, 2009 at 9:22 PM, Jon S. Berndt wrote: Thanks. I do remember seeing the in-cabin movies of the unhappy dummies that were part of the study. You know, if NASA did screw up the final test, maybe someone should suggest the mythbusters redo this on their show? I've got the autopilot here and some local buddies who could do the integration into the full size airplane. I just need someone to buy me a 707. :-) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] airliner ditching miracle ... or not
On Sat, Jan 17, 2009 at 5:43 PM, Jon S. Berndt wrote: Many of you recall the hijacked airliner than ran out of fuel ten or fifteen years ago. The resulting ditching didn't turn out so well, with most people drowning. That was on the ocean near the shore. In the recent case, it appears that everything worked right. The crew - trained for such an emergency - reportedly performed admirably. The passengers did well. Emergency services and boat captains played a vital role. I can imagine that a ditching in the open sea and on a river are in two remarkably different environments, with the river being much more conducive to a ditching. If one engine catches a wave before the other, that could be enough to finish everyone off. I'd imagine that the aircraft *must* land straight forward without rolling, and maintain structural integrity and buoyancy long enough to allow everyone to get out. On my recent trip from Houston to Honolulu (with my entire family, including four kids aged 6 to 12), this was one of my concerns, flying in a two engine aircraft. No matter how skillful the pilot is, [s]he cannot control the ocean state. At the time we flew, there were two tropical storms south of us. I'd imagine that this recent case will be a valuable data point for study to make future ditchings more survivable. I was on a 224' NOAA research ship last spring about 1000 nm north of Hawaii. We were up past San Francisco latitudes and water and air temps were in the low 50's. We were way out of any helicopter range, hardly a ship any where near that area ... if we had to ditch the ship out there, it could have been really ugly ... and that's without the need to survive a water landing in 10-20' swells. We had days with 35 kt winds and you just don't want to be above deck very long (not to mention in the water) in those conditions. I agree that with the A320 incident in New York, a tremendous amount of skill, talent, and preparation was involved. Without all of that coming together at the same time, there wouldn't have even been a chance. Also setting down in a long stretch of flat water gives you a much better chance than trying to set down in ocean swells. But given the circumstances, and given that all aboard survived, I have a hard time not calling it a miracle myself. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] airliner ditching miracle ... or not
On Sat, Jan 17, 2009 at 6:00 PM, syd adams adams@gmail.com wrote: So, how about it? Who is serious about going down that road? I am , for one, which is why I dont get the apperent need to impress the general user community... I didn't think we were creating a game here... I'm currently more interested in getting the glass cockpits to behave realistically , but since I am not a RL pilot , finding accurate information isn't that easy.Theory is great , but doesn't always match RL behavior... Input is always appreciated , with facts and docs to back it up , but not the its wrong because I say so kind of help ... ;) http://www.atcflightsim.com/index.html Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] airliner ditching miracle ... or not
On Sat, Jan 17, 2009 at 6:30 PM, John Denker j...@av8n.com wrote: On 01/17/2009 05:16 PM, Curtis Olson wrote: http://www.atcflightsim.com/index.html If I may be permitted to answer in kind: http://www.atcflightsim.com/pricing.html You are expecting a complete cockpit enclosure, instruments, radio hardware, instructor station software, plush seat, and FAA certification for free? The FAA doesn't certify a software application (well unless you are looking at a PCATD and even there, it's not just the software they are looking at.) For Level 3 FTD certification and above they certify a complete simulator and at least half of their certification tests involve control loading in some way or another. They go so far as to insist that if you move a simulator to a new location, you must get it recertified. If you are thinking about PCATD certification, then you might want to look at: http://fgatd.sourceforge.net/ It's been a while since I've visited that site, but as the page suggests, a big portion of the battle is to find or build some sort of approved control inputs ... apparently the CH product stuff is not up to snuff according to the FAA. Then another huge chunk of the work is documentation. Getting something certified through the FAA involves a lot of painstaking documentation effort to show that you meet every single requirement. There also the need for an instructor station which would be something external to FlightGear itself. In terms of the software itself, sure there are plenty of things you could nitpick, but I'm sure it would take very little additional work to satisfy the FAA on that front. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] airliner ditching miracle ... or not
On Sat, Jan 17, 2009 at 7:00 PM, John Wojnaroski cas...@mminternet.comwrote: Or for that matter http://www.lfstech.com/index.html Good point. :-) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear crahs
I'm using Flightgear via CVS, synced just minutes ago. If I start up at KBUR (Burbank, CA) after a few seconds I get the following error message just moments after the outside view is presented, followed by a hard crash: AI local traffic Cessna-three-oscar-sierra cleared to taxi... ERROR - unable to find path to runway theshold in ground.cxx for airport KEMT Unknown exception in the main loop. Aborting... Possible cause: Resource temporarily unavailable KEMT is near KBUR. This does not appear to be a problem if I start up somewhere else far away from KEMT. Also, this is a reliable crash. It happens every time I startup at Burbank (KBUR) ... it's not a random, once in a while crash. The file generating the last output before the abort is ATCDCL/ground.cxx Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear/props/Makefile.am breakage
On Thu, Jan 15, 2009 at 3:18 PM, Csaba Halász wrote: Fix linkage of test programs with OpenThreads. Well, it now doesn't compile for me. It adds -lOpenThreads, but merrily ignores the --with-osg configure option. What's your compiler error message? I don't see an obvious problem from looking at the files. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear/props/Makefile.am breakage
On Thu, Jan 15, 2009 at 3:54 PM, Curtis Olson wrote: On Thu, Jan 15, 2009 at 3:18 PM, Csaba Halász wrote: Fix linkage of test programs with OpenThreads. Well, it now doesn't compile for me. It adds -lOpenThreads, but merrily ignores the --with-osg configure option. What's your compiler error message? I don't see an obvious problem from looking at the files. For instance, what is LDFLAGS set to in your Makefile in that directory? Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear/props/Makefile.am breakage
On Thu, Jan 15, 2009 at 6:14 PM, Csaba Halász csaba.hal...@gmail.comwrote: On Thu, Jan 15, 2009 at 10:56 PM, Curtis Olson curtol...@gmail.com wrote: On Thu, Jan 15, 2009 at 3:54 PM, Curtis Olson wrote: On Thu, Jan 15, 2009 at 3:18 PM, Csaba Halász wrote: Fix linkage of test programs with OpenThreads. Well, it now doesn't compile for me. It adds -lOpenThreads, but merrily ignores the --with-osg configure option. What's your compiler error message? I don't see an obvious problem from looking at the files. For instance, what is LDFLAGS set to in your Makefile in that directory? I use --with-osg argument to configure. It should figure out the proper -L option from there, shouldn't it? Right, and all the -L arguments should be added to LDFLAGS in the local Makefile in that directory. So I was hoping you would report the value of that variable. This would help us determine if --with-osg did the right thing for you or not. And if it looks like LDFLAGS has the correct options, it would be interesting to double check the OSG directory just to make certain that the requested library is living there. But of course I managed to compile it, I just reported it so it doesn't go unnoticed. If it is intended behavior, then it is fine with me. Well, if a broken compile is intended behavior, I'm not sure who would intend it to be that way! :-) Then again, all the test and utility stuff should be a separate makefile target, IMHO. For example, in FG only the tests require glut. Or all these things could be ported to OSG, but no one has quite gotten around to it. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear/props/Makefile.am breakage
On Thu, Jan 15, 2009 at 6:47 PM, Csaba Halász wrote: On Fri, Jan 16, 2009 at 1:22 AM, Curtis Olson wrote: On Thu, Jan 15, 2009 at 6:14 PM, Csaba Halász wrote: On Thu, Jan 15, 2009 at 10:56 PM, Curtis Olson wrote: For instance, what is LDFLAGS set to in your Makefile in that directory? I use --with-osg argument to configure. It should figure out the proper -L option from there, shouldn't it? Right, and all the -L arguments should be added to LDFLAGS in the local Makefile in that directory. So I was hoping you would report the value of that variable. This would help us determine if --with-osg did the right thing for you or not. And if it looks like LDFLAGS has the correct options, it would be interesting to double check the OSG directory just to make certain that the requested library is living there. LDFLAGS = -L/home/hcs/src/inst/sg-dbg/lib -L/usr/X11R6/lib Which is interesting, because that's the path I am going to *install* it to. So why add that? I believe the --prefix= path is always added. This is a convenience because often times you end up installing the prerequisites in the same --prefix location. Configure arguments were: --with-osg=/home/hcs/src/inst/osg --prefix=/home/hcs/src/inst/sg-dbg --with-jpeg-factory Ok, I wonder if --with-osg is failing in some way. I'd be interested in seeing the output of your configure run, and if you are doing that, you might as well include the config.log ~/src/inst/osg/lib$ ls -l libOpen* lrwxrwxrwx 1 hcs hcs 20 2008-11-19 19:37 libOpenThreads.so - libOpenThreads.so.11 lrwxrwxrwx 1 hcs hcs 23 2008-12-30 04:41 libOpenThreads.so.11 - libOpenThreads.so.2.3.1 -rw-r--r-- 1 hcs hcs 127456 2009-01-15 17:52 libOpenThreads.so.2.3.1 Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG ocean water shader / water region issue.
On Wed, Jan 14, 2009 at 9:35 AM, Martin Spott wrote: James Turner wrote: I've idly wondered about pulling the water out of the generated scenery, and instead creating 'ground' down to the low tide line. The water surface could then be created at runtime, allowing for tides, waves, and other effects depending on the GPU/CPU power available. Secondly, PROPER DESIGN using bathymetry 'elevation' data we'd certainly be able to create seabed 'Terrain' for Ocean and probably also for Lake areas /PROPER DESIGN - probably not as detailed as the regular surface but sufficiently accurate to model the seabed for example within the twelve mile limit (just to put a figure). This would allow for simulation of tides and the resulting effects at a later development step. My sense is that there are many areas in the world where the slope of the shore line is very shallow. Also don't forget that our SRTM data has a resolution / random noise element of about +/- 5 to 10 meters. I think that these things combined together could lead to some extremely inaccurate shorelines and odd contour artifacts if we try to physically model the water level and the terrain elevation to create a shoreline. It's a neat idea and certainly could be worthwhile territory to explore, but I'm pretty sure it will yield highly inaccurate shorelines with ugly artifacts in many areas of the world. And there are many hidden dangers I would think. If we get the ocean level off by a meter or two and the land off by a meter or two, we could have unintended side effects such as putting all of KSFO under water at high tide. So I agree that this is a very intriguing idea to explore, but I would stop short of calling it proper design compared to what we are doing right now. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG ocean water shader / water region issue.
On Wed, Jan 14, 2009 at 10:36 AM, Martin Spott martin.sp...@mgras.netwrote: Well, currently we're 'adjusting' the Terrain to a hypothetical shoreline in a very simple way: Everything that lies within the VMap0 definition of political boundaries (our current coastline) is defined as ground and any SRTM point that lies outside this area is getting ignored - even if it lies remarkably above MSL, no matter if the SRTM elevation and/or our coastline are valid or not. I don't see any reason not to apply the reverse schema to bathymetry data. The real cause of trouble is not our elevation data, it's the coastline - due to the corresponding landuse data we're currently using. As a side note: Before disesteeming my approach as being just a neat idea, your sense should get an update about the accuracy of SRTM-derived shorelines (SWBD et al.). I know, they _do_ have huge inaccuracies, notably at mudflats, but in the overall picture they're not much worse than our current approach of telling between ground and sea. And your sense should also get an update about all the small airfelds and large airports which are sitting out in the sea _now_. I've always lobbied for using the GSHHS shoreline database because I feel that is the best shoreline database we have available. However, for a variety of reasons we have ended up using political boundaries of VMAP0 which as you state is less than ideal. (1) VMAP0 has some significant inaccuracies (2) assuming anything outside of political boundaries is ocean causes the great lakes in north america to be rendered as ocean at 0 MSL. I still would like to find a way to move back to the GSHHS data set if we can figure out a way to resolve problems with combining that data set with VMAP0 freshwater data (which often conflicts with GSHHS ... things GSHHS considers freshwater might be considered outside political boundaries in VMAP0 and visa versa so you can't marry the two data sets cleanly.) Sorry, didn't mean to press the wrong button here, but just wanted to provide some realistic feedback. I think the problems will be more difficult than you imagine, but certainly you are welcome to push forward. Every scheme has pluses and minuses, so if you can push through the difficult portions, maybe you will be able to come up with something better than what is available now. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG ocean water shader / water region issue.
On Wed, Jan 14, 2009 at 12:23 PM, Martin Spott martin.sp...@mgras.netwrote: I'm quite aware of these implications - this is what I've been pulling together into the due to the corresponding landuse data- phrase. It's not only about freshwater, basically this affects any sort of ground coverage that is meant to match the coastline. OFF TOPIC: As (probably just a) few of you know I've started planning, installing and improving the required infrastructure to store, visualize, compare, merge and edit different datasets four or five years before now (even before OSM got public ). I've also been inspecting numerous datasets (including several coastlines), investigating methods for editing the data remotely and spending quite a lot of time on other involved stuff. In FlightGear slang (TM) I'm therefore to be considered as being a mere lurker :-))) /OFF TOPIC Even though I've been advertizing this side project occasionally, it has seen just very limited attention and support from other FlightGear fellows (I know that I'm bad at advertizing ;-)) Every time I've been gathering for support, people typically fell back into silence (the usual procedure) and as long as the few involved people have to do _everything_ themselves, things proceed still steadily, but slowly. If there were some fellows ready to jump into this effort without asking for a readily usuable graphical interface unless they move their little finger, we could already have VMap0 landuse and GSHHS (or whichever) coastline merged together. BUT, the story about merging vector data is still not right on topic. Your response lacks an explanation why you consider it as being impractical to blend the bathymetry data against the coastline in the same manner as we're currently dealing with the SRTM elevation grid. I thought I fully explained what I thought was the biggest potential difficulties with your approach: (1) SRTM data has +/- 5 to 10 meter error built in. In land regions with a very flat slope leading up to the coastline that can lead to things like hundreds of meters of coast line inaccuracy, or very odd artifacts and very unnatural boundaries. How about the Dead Sea or Death Valley? (2) I think it will be very easy for entire regions to get put under water if there are small errors in terrain elevation or small errors in tide computation. Sorry, didn't mean to press the wrong button here, but just wanted to provide some realistic feedback. No, you didn't push the wrong button, you've simply trying to discredit my effort and ideas without proper evaluation. E, if that's what you think, I guess I'm not going to be able to talk you out of it. In actuality, it is my engineering brain looking for the biggest challenges first and vocalizeing them. If you can get over the biggest humps then the rest of the journey is down hill. Again, I'm sorry if you didn't read it that way. If you think I'm trying to discredit your ideas here, then you are simply way way way off, and that I can't do much about. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] UDP communications with FlightGear!
On Fri, Jan 9, 2009 at 3:53 PM, Csaba Halász wrote: On Fri, Jan 9, 2009 at 6:30 PM, John Miller wrote: --generic=socket,in,10,,5500,udp,FGWriter1 --fdm=null Every time I run the programs with these parameters, FG crashes and I get back the following messages from the log Error: bind() failed in make_server_socket() This usually means that port 5500 is already in use. Ahh, yes, double check you aren't trying to use the same port for both communication channels (or using 5500 for something else.) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Supply (voltage) for instruments: True, 1.0, 12.0, !=0 ?
On Fri, Jan 2, 2009 at 7:39 AM, James Turner wrote: On 2 Jan 2009, at 13:26, Anders Gidenstam wrote: Could we find more descriptive property names for these voltage/ potential difference properties? Just to make it clear what they are (and avoid confusion with potential future properties, e.g. for current, charge or power). Good point. I'm hopeful that adding a simple current-draw model will be 'easy' (for a given value of easy, naturally) if we start standardising such things, so it'd be great to think about this now, before people start using new property names. systems/electrial.cxx would be a good starting point for this - it's simplistic right now, but a few more component types (especially a fuse)[1], and a Nasal interface to allow the electrical system to be controller trivially by an aircraft designer, and it'd be pretty respectable. FGElectricalOutput is pretty close to my proposed base class for electrically powered instruments - it needs some extension, but it makes sense to aggregate (in the C++ sense) that functionality into instruments. James [1] - whoops, FGElectricalSwitch provides a circuit-breaker function. Once again proving that for everything you might want to do, FG already contains code for it, you just need to find the code :) However, the existing XML based electrical system model is extremely difficult to use from an xml configuration standpoint, and although it worked ok for the c172 electrical system, I began to run into core design barriers when i was attempting to implement the electrical system for a light twin. I really don't recommend the xml/C++ electrical system for future use. Instead, it's *far* easier and much more straight forward to build up a procedural model in nasal. This is actually a very good job for nasal because aircraft electrical systems are wildly different from each other, and nasal allows you to write a per-aircraft electrical system model. This point has nothing to do with voltages being normalized or not, but hopefully that provides some background. Personally, I prefer working in real volts. The one side of the equation that has never really been addressed is current draw, and again, that is probably best done in real numbers for sanity and maintainability. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Supply (voltage) for instruments: True, 1.0, 12.0, !=0 ?
On Fri, Jan 2, 2009 at 10:19 AM, James Turner zakal...@mac.com wrote: On 2 Jan 2009, at 13:50, Curtis Olson wrote: However, the existing XML based electrical system model is extremely difficult to use from an xml configuration standpoint, and although it worked ok for the c172 electrical system, I began to run into core design barriers when i was attempting to implement the electrical system for a light twin. I really don't recommend the xml/C++ electrical system for future use. Instead, it's *far* easier and much more straight forward to build up a procedural model in nasal. This is actually a very good job for nasal because aircraft electrical systems are wildly different from each other, and nasal allows you to write a per-aircraft electrical system model. I don't think doing the complete system is Nasal is sensible - in the future we might want to apply a 'real' electrical model, which requires an iterative matrix solution, or something comparable (I think it's actually solving some differential equations for each node in the circuit, for example). The set of elements is very small, and well defined (as seen in the existing C++ code) - batteries, switches, breakers, alternators, and current drains. A few specialised derived types could be added, especially for lamps (which are very visible), and which occur frequently. And absolutely, this should be configured and defined through Nasal, since clearly the arrangement of the above in each aircraft differs wildly. But that doesn't mean we shouldn't express (and expose!) the core graph to C++, for simulation, fault-modelling and various other purposes. The same is true of the hydraulic system - and indeed, many of the components work the same way. The problem is that as you get beyond a simple single engine electrical model with multiple generators, multiple batteries, all the different feed paths and protection circuitry, etc. life gets really complicated. Now you want to compute proper current draw based on sensors at different points in the system it gets way worse (the current xml based system isn't capable of doing that properly.) And then if you want to start adding some fault modeling for real pilot training it becomes completely insane. The problem with an electrical system model that can compute the result when you throw a bunch of parts and connections at it, is that the complexity explodes on you when you begin to look at all the different requirements. I'm not saying it's impossible, and I'm not saying we don't want such a detailed modeling system in our code. But trust me, no aircraft modeler other than myself (that I'm aware of) ever made any serious attempt at crafting up an xml based connection chart to actually model the correct electrical system of their aircraft. With nasal it is 100x simpler and more straightforward to procedurally meet all the objectives of providing power to the instruments and subsystems, computing loads, and doing fault modeling. Again, there's no reason you can't push forward and build a system that models all the physical properties of an electrical system at a low level. You might be tempted to adapt the current system, but it is hopelessly flawed and you will probably be better off starting from scratch if you really want to produce a system that works. And then to get aircraft designers to actually use it, you'll probably need to design a gui where they can graphically draw up the electrical system and make all the connections. But by then, a 100 line nasal script is starting to look 1,000x to maybe 10,000x easier and faster. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] VOR shack : scenery model upgrade opportunity
On Fri, Jan 2, 2009 at 2:32 PM, John Denker wrote: On 01/02/2009 01:01 PM, Erik Hofman wrote: I've modeled them after these images in the past: http://i149.photobucket.com/albums/s63/tundratantrum/kotzebuevortac1.jpg http://www.dot.state.mn.us/aero/avoffice/navaids/images/vor3.jpg http://members.chello.nl/vdleije/pics/ssj_vor.jpg Wow, those are small. I can say from personal experience that Gopher (GEP, 117.30) is really tough to spot from the air. Of course you are talking to a guy who gets lost after about the first 30 seconds after take off (assuming I don't look out the window sooner than that, in which case I'd be lost sooner.) :-) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] amazing FDM initialization bug
The way this was explained to me is that JSBSim only performs the wow test when it is within 200' of the ground. Unfortunately, this means that if you start in the air higher than that, the gear variables can be left in an unsettled state because the test that sets the variables never gets run. Regards, Curt. On Wed, Dec 31, 2008 at 11:57 AM, John Denker wrote: I have a pretty-much workable workaround for the worst of these bugs. The big clue is that presets-commit apparently just deletes the old FDM instance and creates another. To make the new FDM happy, I had to delete a bunch of nodes from the property tree. Some other nodes needed to be set to -; merely deleting them was not good enough. This allows me to relocate-in-air once without getting flipped upside down (or worse). There is still some opportunity for improvement in connection with presets-commit and with FDM init in general. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] amazing FDM initialization bug
On Wed, Dec 31, 2008 at 12:35 PM, John Denker j...@av8n.com wrote: On 12/31/2008 11:20 AM, Curtis Olson wrote: The way this was explained to me is that JSBSim only performs the wow test when it is within 200' of the ground. Unfortunately, this means that if you start in the air higher than that, the gear variables can be left in an unsettled state because the test that sets the variables never gets run. That's the least of my worries, for several reasons. I've always thought the 200-ft business was a weird optimization, especially since other properties such as gear-extension-norm are recomputed at frame rate at all altitudes. And that is the solution for retractable-gear airplanes: forget about wow and just look at gear-extension-norm. I just hope the latter never gets optimized into never-never land. At one point the wow property was fixed so that it would be updated at least once above 200 AGL, but the fix evaporated. And I don't care anymore. I'm happy to use gear-extension-norm. Far more troublesome is the behavior of presets-commit, which still has a tendency to put the FDM into unrecoverable states, such as uncommanded vertical pitch attitude and zero frame rate. Once the users intentions have been communicated to the FDM module, it's really up to the particular FDM, (JSBsim or YAsim) to do the right thing with the provide information. That does seem to have broke down at some point. I used to be able to happily start both YAsim and JSBsim aircraft in flight, but had zero luck last time I tried. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] logging ( was Re: COMM radios (Debug aid))
On Tue, Dec 30, 2008 at 5:03 AM, James Turner wrote: On 30 Dec 2008, at 09:51, Alasdair Campbell wrote: Looking initially at the atis.cxx, ATCmgr.cxx, etc code I notice a bunch of commented-out cout statements, which give me a good idea of where to look for solutions. I wonder if there is a case for introducing a -v (--verbose) option for turning all occurences these statements ON via an IFDEF condition. Suggestions on where to introduce such a condition welcome. I would be willing to undertake the grunt work. Long live find/grep/sed. (sadly I can't offer much useful advice on the radios front, but as a more general thing:) We already have this, it's the SG_LOG() mechanism, which wraps a C++ iostream (like cout) with a module and level parameters. You can set the log-level in various ways (eg, from .fgfsrc) or using --log-level on the command line. By default, SG_ALERT is shown - the 'lower' levels are warning, info, bulk and debug. The problem is, there's code which uses INFO where it should probably use BULK or DEBUG, and so info is a a bit much to deal with, and BULK is more or less impossible (interactively). It's fine for recording to a text file and then grep-ing / sed-ing of course. Also, for any of these lines, we pay all the string manipulation penalty regardless of the whether the message is logged or not. In some code this cost is potentially significant, especially inside loops. (One I just killed: the apt loader was looking each line in the file to BULK as it read it) My personal feeling is that DEBUG should be for debugging, i.e removed once the code in question is in a stable, and that longer term we should be considering what BULK is really useful for. Being able to grep/sed/find in logs is nice, but finding a way to avoid the runtime cost when the messages are suppressed (which is 99.99% of the time) would be equally nice :) Originally this scheme was designed to completely collapse out of the code when not in use, but I'm not sure if that feature has been maintained over the years. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Panel designers: feedback needed
On Sun, Dec 28, 2008 at 9:38 AM, James Turner wrote: I'm planning to create some slightly advanced cockpit instruments in the near future, and to do this I need to support some more complex text displays. (This is for the character-based displays on the KLN89/94/etc GPSs, and FMS/MCDU units in the longer term). I was intending to create some specialised (scriptable) layers in the current 2D panel format, which would be more advanced variants on the current text and chunk system that already exists. However, to do this, I need to fully convert the existing 2D panel code to OSG - this would have various benefits, but it's a non trivial amount of work. However, there seems to be some confusion about the preferred way to builds new panels, going forward. Clearly many panels contain 3D elements (knobs, levers and the like) which are not expressed using the 2D panel XML format. Equally, as far as I can see, all the analogue and digital panel displays are still being created using the 2D system, i.e transform, select, cropped-texture layers and so on. Is this correct, or I have mis-understood something here? I don't want to spend time converting the old code to OSG if it's a dead-end that is only used by older panels. If it's been superseded, where is the system that replaces it? In my opinion, the 2d instruments are still very useful for people that are setting up full screen panels as part of a larger simulator where the out-the-window view is drawn on separate monitors and the there may be one or more displays embedded in the instrument panel used to draw instruments only. The 3d panels are nice if you want a virtual environment all in one single display, or if you are in a cave type environment. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] porting in CAVE.
On Tue, Dec 23, 2008 at 5:47 AM, Amit Vyas wrote: Hi all , I am new to flightgear,and using following for compilation on a windows XP machine 1. freealut-1.1.0-bin 2. plib-1.8.5 (src) 3. SimGear-1.0.0 (src) 4. zlib123 5. fgfs-base-1.0.0 6. FlightGear-1.0.0 (src) I am trying to understand some code to create flightgear's CAVE version ( CAVElib 3.1.1 ) Any thoughts on this would be welcome it. To start off if I can get FlightGear into multiple sub projects that would be great because it takes too much time to get it compiled on my machine, having divided into sub projects will help me a lot to understand portions where I need to work. Hi Amit, If you peruse the source code layout you will find that FlightGear is indeed divided into numerous sub-libraries. They aren't setup as individual projects though (especially not in the msvc sense of the word.) The 1.9.0 version of FlightGear already supports multiple displays and multiple windows (each with their own unique perspectives), and FlightGear can sync multiple computers together over a network. I think you could put together a pretty convincing cave demonstration with just the stock v1.9.0 code. The only thing perhaps that is missing is head tracking and someway to operate the aircraft. I had good luck once hacking a wii-mote to function as a joystick and was able to fly quite nicely with it. Head tracking won't be important for out the window views since you are so far away from the world that head motion really won't affect your view. But head tracking probably would be pretty nice for looking around the 3d cockpits. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] screenshots for v1.9
Yes, if any one would like to submit screenshots of the latest aircraft, or scenery, or environmental effects or rendering features, please do and I can begin assembling a new set of images. However, so far no one has submitted any new images to me so I haven't had to worry about it. :-) Curt. On Mon, Dec 22, 2008 at 5:49 AM, Melchior FRANZ wrote: Durk has suggested that I repeat some of my screenshot tips, as we need stunning new screenshots for the flightgear.org website. (What I write isn't binding, as I don't do this in any official function.) (1) contents: Obviously, screenshots should focus on new features/scenery/aircraft. Those should be generally available, ideally from our repository, but at least freely downloadable on the net under GPL compatible license terms. Please no aircraft etc. that are proprietary or unreleased. (2) quality: - use highest feasible filter settings (antialiasing, etc) - hide frame rater counter, menu, dialogs (unless they are part of what you want to demonstrate) - use realistic scenarios: no 747 approach to the Nimitz etc. - avoid the display of fgfs shortcomings: no rain in cockpits, no cloud artifacts, no floating aircraft, no transparency problems. (Yes, that's cheating. But people know that any software (apart from TeX :-) has bugs, and demonstrating bugs is not the purpose of our screenshots.) - please understand that, in case there are *many* submissions, Curt has to choose the better ones. (Unfortunately, that's not usually one of our main problems. ;-) (3) legal matters: though there's no official decision yet about which license the screenshots should be under, the outcome of a recent discussion implies that the rules set out under http://wiki.flightgear.org/index.php/Submitting_Screenshots should be valid. (A review by the FSFE -- the Free Software Foundation Europe is still pending.) No exceptions, please! Distribute your screenshots *yourself* under whichever license you want, but accept that FlightGear distributes them under these terms. Otherwise don't submit any. (Unless Curt decides otherwise, of course.) (4) tools: Some older systems don't run well with high-quality filter settings. People with such systems can use the attached script to work around that: - save it to ~/.fgfs/Nasal/ (create this dir if necessary) - create a directory ~/.fgfs/Export/ - run fgfs normally, find good motive, pause, press Ctrl-q to save an XML snapshot of the situation - re-run flightgear with that situation and with antialiasing etc. turned on: $ fgfs --aircraft=ufo ~/.fgfs/Export/snapshot-KSFO-bo105-1.xml - find perfect sun angle, weather, perspective, then make the screenshot with F3 m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear web site is updated.
Hi, In preparation for the official v1.9.0 release announcement, I've made many updates to the flightgear web site and download pages, including many updates to the aircraft downloads page. It would be great if as many people as possible could go through the web site and try the various links and make sure everything is working and there aren't any serious mistakes or pages that are way out of date. Aircraft authors should check out the entries for their aircraft on the aircraft download page, and make sure they like the thumbnail image and the version and authors are correct. These aircraft download packages as well as the download page is all autogenerated from scripts, and all the information about authors and versions is contained within your aircraft. If you have any questions, look at an example aircraft that does things the way you like. :-) Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear web site aircraft download page
It was looking for description tags in the -set.xml file ... I changed it to stop looking after the first one. Curt. On Sun, Dec 21, 2008 at 4:48 PM, Alexis Bory - xiii alexis.b...@gmail.comwrote: Curtis Olson wrote: These aircraft download packages as well as the download page is all autogenerated from scripts, and all the information about authors and versions is contained within your aircraft. If you have any questions, look at an example aircraft that does things the way you like. :-) Hi Curt, On the aircraft download page I note: *A-10*: Fairchild A-10 (YASim FDM) tank-600-gals AN-ALQ-131 dual-AIM-9 LAU-68 triple-MK-82-LD single-MK-82-LD none none none none none none none none none none none Well I don't really know how to avoid this list of ordnances to appear... Wouldn't the script be overzealous ? Thanks for your help, Alexis -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
There's no reason the chooser can't be made to run on any of our supported platforms. It's written in fltk I believe and I've had it running in Linux in the past. The only reason it might seem like it's a win32 only app is that Frederic is really the only one who has taken the time to bundle it with his binary build. Regards, On Sat, Dec 20, 2008 at 9:53 AM, Syd wrote: Well, and what about using a graphical aircraft chooser. I know a good one ;-) -Fred PS: fgrun if you didn't get it. Its great for Windows users , but I dont use such things :) -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
On Sat, Dec 20, 2008 at 12:58 PM, Jon Stockill wrote: Curtis Olson wrote: There's no reason the chooser can't be made to run on any of our supported platforms. It's written in fltk I believe and I've had it running in Linux in the past. The only reason it might seem like it's a win32 only app is that Frederic is really the only one who has taken the time to bundle it with his binary build. Not quite true - it's been included in the Slackware Linux packages too. Excellent ... real proof it's not just a win32 application. :-) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] METAR interpolation?
I just did a cross country flight with the latest CVS cloud/weather/metar changes and I noticed that the weather interpolation that smoothed out abrubt changes to wind and clouds when a new METAR report comes in seems to have now been lost. We are back to abrubt wind and cloud changes. I haven't had a chance to dig in myself, but thought I'd mention this to the folks that currently have their heads immersed in that section of the code. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler
On Fri, Dec 19, 2008 at 4:55 PM, James Sleeman flightg...@gogo.co.nzwrote: Some time ago there was discussion on the list regarding the loss of doppler sound effect in the fly-by view, I was sure I read that it had been resolved? I still have no doppler in the fly-by with a fresh build last night, am I the only one, or is it still broken? This should be resolved. Can you tell me which aircraft doesn't have the doppler sound effect? What frame rates are you experiencing when you have no doppler effect? Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
On Tue, Dec 16, 2008 at 9:42 AM, Tatsuhiro Nishioka tat.fgmac...@gmail.comwrote: I guess Tim means 1.9.0, not 2.0. Actually 1.99.5 is just a temporal number for fgfs/cvs and (I believe) we're heading to 1.9.0. Curt told us that he put 1.99.5 since he had missed the discussion on this list about the version number for the first OSG release. This is why I gave 1.9.0-preN to mac binaries. Got confused? The final dicision will be made soon, so we'll see. Anyway, shorter release cycle can give flightgear a chance to get more attension, so I like that idea. If quarterly releasing cycle is a bit too often, then semiannual is fine for me. What do you guys think? Personally, I think a big build up to an oddball version number like 1.99.5 is a little strange, but again, I'm not so hung up on version numbers as long as they keep increasing. It would also be odd to backtrack since the point of version numbers is to distinguish releases in some logical order. I had in my mind that there would be a 1.99.x release sequence as a build up to a major v2.0 release (rather than 1.99.5-rcX building up to a v1.99.5 release.) So there are some crossed wires here that unfortunately is leading to a weird version number situation. In the meantime, I have been working on a script that will streamline the release process a bit. My hope is to start doing more frequent source releases once this major release is pushed out the door. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Final (?) 3D clouds patch
On Mon, Dec 8, 2008 at 2:18 PM, dave perry [EMAIL PROTECTED] wrote: The 3D cloud appearance is much improved. Thanks to all involved! Several questions and comments. 1. At night, the emmissive seems very very bright. 2. Are you intending that the 3D cloud base should match the lowest level in the current METAR? I just flew with a KDSM METAR using real weather fetch (current METAR copied from ADDS:* KDSM 081954Z 10007KT 10SM BKN130 OVC160 01/M03 A2964 RMK AO2 SLP047 T00111033. * ) This gives a broken layer at 13000 ft AGL but the 3D clouds started at 2000 AGL. 3. When I took off, the outside view showed the clouds flickering. I wonder if there is some sort of floating point resolution / rounding problem with the sort? I see a lot of flickering myself. Also if I look some particular direction and the clouds get sorted ok, then look away for even a second, and then look back (by changing the view direction) the clouds seem to have totally lost their previous correct sort and need to be sorted again ... but that doesn't happen until the clouds come back in view. I'm not sure what the sort criteria is, but it seems strange that the sort order would get messed up in a brief second of not having a particular set of clouds in view. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery download
On Fri, Dec 5, 2008 at 6:31 AM, Fabian Grodek wrote: Hello, I've been trying to checkout FlightGear source code from the CVS Repository but I always get the message: Logging in to :pserver:[EMAIL PROTECTED]:2401 :/var/cvs/FlightGear cvs [login aborted]: /var/cvs/FlightGear: no such repository A similar message I get also with Tortise client. Can anybody be so kind as to tell me what am I doing wrong Due to historical reasons, the repository is named /var/cvs/FlightGear-0.9/ Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Yet another Clouds Patch (again)
On Thu, Dec 4, 2008 at 2:12 PM, Stuart Buchanan wrote: Hi All, Attached is yet another patch for 3D clouds. Could someone please apply it to CVS? This provides the following enhancements bug fixes - Fix the chequer-board bug. - Add proper cloud coverage function - so scattered clouds are now truly scattered. - Add real-time control for visibility range. - Use a limited set of clouds rather than generating a completely new Geode for each cloud. This saves sorting and display time. - Add controls to Rendering dialog to allow fine-tuning of the number of sprites, cloud visibility and the number of different types of cloud. - Add some variance to the sort back-off to avoid all clouds being sorted at the same time. - Pack attributes into vectors for performance - Re-order the cloud type determination code so that if a cloud layer could either be stratus or cumulus, cumulus is used. - Lowered the cloud level in the standard cloud configuration slightly so a cumulus layer is generated rather than stratus. These last two mean that you should see some 3D cumuli if disabling real weather fetch. My thanks to Yon Uriarte for his help with performance work. On my system, this has saved around 10fps - I'm now getting around 38fps instead of 28fps. As always, feedback is appreciated. I could easily be doing something wrong, or have inherited some configuration setting from a previous version, but before today's patch I had 3d clouds, and now I do not. This is with OSG 2.7.5. Is there anything I can quickly double check? Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Another simple question
On Thu, Dec 4, 2008 at 3:52 PM, Durk Talsma wrote: On Thursday 04 December 2008 14:42:02 Arnt Karlsen wrote: On Thu, 4 Dec 2008 11:20:51 -, Gordon (UK) wrote in message Now, I'm working in Visual Studio. However, how the devil do I set up [EMAIL PROTECTED]:~ $ apt-cache show ccache distcc [ Lots of uninformative text deleted ] Depends: libc6 (= 2.7-1), zlib1g (= 1:1.1.4) Did you notice that Gordon was asking for advice on how to prevent excessive compilation using Microsoft visual studio? That clearly leaves any unix related solution out of the equation. As such, this answer was not particularly helpful. Gordon, Many flightgear developers do run linux, but also many run Windows or Macintosh. It's never been an official position of this project to advocate one operating system over another, but instead to do our best to support all the major platforms that people are running today. And by supporting multiple platforms and compilers, we are probably better positioned than most other commercial software packages to hop to the next popular If you ask me or any other developer personally, we do have plenty of biases, and those probably leak out once in a while. Anyway, hopefully a windows developer can jump in with some help ... Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Yet another Clouds Patch (again)
On Thu, Dec 4, 2008 at 4:49 PM, Martin Spott wrote: Curtis Olson wrote: I could easily be doing something wrong, or have inherited some configuration setting from a previous version, but before today's patch I had 3d clouds, and now I do not. This is with OSG 2.7.5. Is there anything I can quickly double check? The current weather !? ;-) I just experienced a similar effect and after switching the startup position from KSFO to EHAM I got the clouds back I did think of that after scratching my head a while ... the metar reported several cloud layers and I did try to switch to a new location as well as switching to fair weather and thunderstorm ... I did get snow and rain, but with a perfectly clear sky. I can try to re-cvs update and re-compile things again if other people are working with todays patches ... Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c172p pitch at cruise question
We really want to make sure that the visual model is correctly aligned with the dynamics model. Then if the 3d model isn't sitting correctly at rest on the ground, it could be that the gear lengths aren't set properly in the 3d model compared to the dynamics model, or visa versa. If everything is self consistent, it should sit nicely on the runway. And then if the pitch angle is visually off in flight, it probably makes more sense to fix the flight dynamics configuration to achieve the correct cruise pitch instead of hastily rotating the visual model a few degrees to compensate for a flight dynamics deficiency, and also a mismatch in dynamic model gear length versus 3d model gear length. I'm not saying that is the problem, just that it seems more likely to me since we have a added a new 3d model to an existing flight dynamics configuration. Regards, Curt. On Thu, Dec 4, 2008 at 7:02 PM, gerard robin wrote: On vendredi 05 décembre 2008, gerard robin wrote: On vendredi 05 décembre 2008, dave perry wrote: dave perry wrote: Hi All, snip Would it not be more realistic to rotate the 3D model about -3 or -4 degrees about the ac3d z-axis. I did not make myself clear in the initial questiion. The video link only detracted from my point. The model in the .ac file is just a rigid body that gets displayed when the fdm says the pitch is zero degrees (or perhaps zero incidence). The fdm then rotates this rigid model for other flight conditions. So if the model starts 3 or 4 degrees too nose high for realistic cruise, it will remain 3 or 4 degrees too high in pitch for all other rotations from the fdm. In particular, it will be 3 or 4 degrees higher than a realistic stall at touch down, burying the tail cone in the runway. To make this clear, I opened the c172p.ac in ac3d, made a screen capture of the side view, then rotated the model by - 4 degrees and made a 2nd screen capture of the side view and then scaled and combined these into one small .png which is attached. My only point is that I think the rotated side view pitch (bottom image) looks like a c172p at cruise and the original side view (top image) looks like a c172p in level no flap slow flight. Compare the wing and horizontal stab incidence angles in the two images. In the rotated side view, the horizontal stab is at zero incidence while the non rotated side view shows a noticeable positive incidence for the horizontal stab which would normally require significant up elevator to maintain. Making this change will be a lot of work since the panel will be messed up. I know because I made a similar rigid rotation correction about a month after I first submitted the pa24-250. No if that was necessary , their is nothing else than modification of the offset in the c172p.xml model. The panel should follow However i noticed that with the actual position the model has the nose gear up above the ground. An offset of -2 deg would be nice pathc172p.ac/path offsets pitch-deg-0/pitch-deg /offsets oups err offsets pitch-deg-2.0/pitch-deg /offsets may be more Dave P. -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with 1.99.5
I think this is fixed now in cvs, but nothing will happen until a new tarball is generated (using make dist) Regards, Curt. On Wed, Dec 3, 2008 at 6:44 AM, Jon Stockill wrote: Anyone else having issues building this? I'm getting: config.status: error: cannot find input file: utils/propmerge/Makefile.in When trying to build a clean extract of the source tarball. Jon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with 1.99.5
On Wed, Dec 3, 2008 at 9:31 AM, Jon Stockill wrote: Curtis Olson wrote: I think this is fixed now in cvs, but nothing will happen until a new tarball is generated (using make dist) I haven't seen any problems with CVS recently, but I was just updating my build script ready for a release and so was running it against the RC tarballs. There can be subtle differences between what you get on a cvs checkout or update versus what you get from make dist and the resulting tarball. make dist only knows about what is referenced in the Makefile.am's ... so it's possible to add a .h file (for instance) to cvs or a new directory without providing the proper references in in the Makefile.am files and the files will be there in cvs, but not in make dist ... it seems like I often catch a couple of these for each new release. I'm not horrified though since there are a lot of subtleties in the automake/autoconf system that I wouldn't expect every developer to fully understand. Just out of interest which version of OSG are people planning to link the release against? Are we going to wait for a 2.8 release, or go with one of the 2.7 developer releases? I have a problem building a dependency against some development version of a library which is only available from cvs (note the mess that openal can often be on many platforms) OSG is a little bit better in that there is a real tarball with a real version we can download and build against ... even if it's not an official stable release. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGNetFDM version 24
Hi Jan, You could work your way back through the previous versions at the following link and extract the version that matches what you want (or just scroll down to the version tagges as RELEASE_0_9_8 and that should get you pretty close: http://cvs.flightgear.org/viewvc/source/src/Network/net_fdm.hxx?view=log If you are able to compile yourself, you could probably just drop in this older version instead of the current version and remove any references to non-existent fields in the code (follow the error messages and clean them up one by one as you compile.) The needed changes should be concentrated in probably just the native_fdm.cxx file. (This would break compaitibility with newer versions of flightgear if you wanted to exchange the FGNetFDM packet, but you probably wouldn't need to do that ...) Regards, Curt. On Wed, Dec 3, 2008 at 12:19 PM, Jan Černý wrote: Hello, I'm new to FlighGear and I have folowing problem. I have downloded and installed AeroSim blockset and I am trying to use it's block interconnecting Matlab with FlighGear (native-fdm protocol used). However, I found that it's working only for version 0.9.8 or older. They are using older version of FGNetFDM structure (version 20). I have FG v1.0.0. and tried to derive FGNetFDM version from the received structures and the version should be 24, I hope :). Can I ask you where can I found specification or file containing definition of FGNetFDM v.24? Thank you very much for your help. Jan Cerny - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tarball of bleeding edge CVS snapshot
On Tue, Dec 2, 2008 at 9:29 AM, Csaba Halász wrote: On Tue, Dec 2, 2008 at 3:48 PM, Fabian Grodek wrote: Hello, I've been unable to open the link to the tarball of the bleeding edge CVS snapshot found in the Download Souce page: http://cvs.flightgear.org/cgi-bin/viewvc/viewvc.cgi/source.tar.gz?view=tar Is something wrong with that page? Tarball has been disabled for some time, maybe just an omission and not intentional. Would be nice to have it back. Curt? I forget the issue off the top of my head, but somehow this was broke on the new server or the new version of viewvc and I was unable to find a solution in the time I had available to concentrate on the problem. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c172p pitch at cruise question
On Tue, Dec 2, 2008 at 9:21 AM, Martin Spott wrote: - With a 'properly' (TM) inflated front wheel damper, the C172 has the tendency of having its tail surprisingly low when standing on the ground at a common configuration: Max fuel capacity, one pilot (of approx. 80 kg) and some utilities in the baggage compartment (a can of oil and such). This one has approx. 50% fuel, no pilot/passenger and just light baggage (additional to the 'utilities'): http://foxtrot.mgras.net/bitmap/EDDI/imm021.jpg - On a slow approach in a real C172 the tail also gets _very_ low above the ground. When watching students flying traffic circuits I noticed several of them getting close to a tail strike - the tiedown ears at a C172's tail sometimes feature noticeable scratches. - Just 10 kts of difference in airspeed (95 vs. 105) have a significant effect on the pitch (to my experience much more than with the DR400 for example), therefore telling from a single video sequence without further information might be misleading. I have some data from a real C172 (again noting that individual aircraft can differ quite a bit depending on weight, balance, and a variety of other factors.) level flight, 90 kts, flaps up ... pitch angle is between 0 and 1 degree. level flight, 60 kts, flaps 10 degrees ... pitch angle is about 6 degrees. level flight, 65 kts, flaps 30 degrees ... pitch angle is about -1 degree. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 1.99.5: Release Candidate
On Tue, Dec 2, 2008 at 7:36 PM, Tatsuhiro Nishioka [EMAIL PROTECTED]wrote: Hi, First of all, many thanks for your effort on this. I've been downloading the tar files but these are still being downloaded and will take about 24 or more hours My network is TFFH but it doesn't help me this time. Could you (or Curt) give a tag (like RELEASE_1_9_0_PRE1) to the source files and base packages in the cvs so I can check out instead of downloading the tarballs? (are we going to release 1.9.0, aren't we. I'm a bit confused with our versioning thingies... We need to have more clear versioning pilocy, but this should be discussed some other time). Part of the confusion is my fault. It was my understanding from discussion a year ago that the 1.x numbers were for the plib branch (most likely 1.0 being the last real plib release.) And then the first OSG based release would be v2.0. I somehow missed the discussion and rational that arrived at a v1.9 version for the first OSG based release. So internally I had been marking the development version as 1.99.x and was up to 1.99.5 (nearing 2.0 in my mind) and had commited that to cvs. I'm working on a script to streamline the releases and have it mostly ready for SimGear, but I decided to hold off pushing that into production until I got a clearer direction of what we wanted to do with version numbers. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Change request for atlas.cxx
On Mon, Dec 1, 2008 at 7:12 AM, Brian Schack wrote: Brian == Brian Schack writes: Continuing in the tradition of responding to one's own posts (I think it was Durk Talsma who mentioned it before), I'm responding to mine. Actually, it's more repetition than response. I made a request for a change to atlas.cxx, but nothing has been checked in yet, so I thought a gentle reminder would be in order. From the original post: Brian Right now, atlas.cxx uses the following code, in Brian FGAtlas::gen_message(), to retrieve the ADF frequency: Brian static SGPropertyNode *adf_freq = Brian fgGetNode(/instrumentation/kr-87/outputs/selected-khz, true); Brian I think it should be changed to: Brian static SGPropertyNode *adf_freq = Brian fgGetNode(/instrumentation/adf/frequencies/selected-khz, true); The motivations for this are given in the original post. Assuming there are no objections, would someone be kind enough to check it in? Sounds reasonable ... done. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] stall horn sound
Hi Dave, I just commited a tweak to FlightGear cvs that relaxes the check for a stationary versus moving view point to account for the moving view offset as the aircraft flies by. See if things work any better for your now. Curt. On Sun, Nov 30, 2008 at 8:24 PM, Curtis Olson wrote: On Sun, Nov 30, 2008 at 7:57 PM, Curtis Olson wrote: Hi Dave, I can at least replicate the problem here. I will see if I have any remaining energy this evening after I get the kids to bed. I'm looking at about line #629 in src/Main/main.cxx ... the first thing I would check is if the moving/stationary view point logic is working for these aircraft without doppler effects. I can tell you that current_view-get_view_pos() is moving a non-trivial amount with these aircraft that have the view center position offset. It's almost like the view position is sweeping around by whatever the offset is versus being at a fixed position. So the next step might be to look into the view manager code to see why the view position computation doesn't produce a stationary point when there is a model view offset defined? Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/http://baron.flightgear.org/%7Ecurt/ -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] stall horn sound
Hmmm, I don't see anything obvious in the code that would cause this. Actually, you should only get the doppler effect in stationary views. Chase views will inherit the model velocity. But you should get doppler effect in the fly-by view and tower views ... is this not the case? Curt. On Sun, Nov 30, 2008 at 2:43 PM, dave perry wrote: Curtis Olson wrote: I've done some work on the sound system in main.cxx and have attached a patch for folks to review if they want to look at what I did. I made a simplifying assumption that the listener is either stationary (stationary enough) or it is tracking with the aircraft model position. ... SNIP Then I used my simplifying assumption to set the listener velocity vector to (a) zero if the listener is stationary or (b) the model_vel if the listener is moving. This seems to really help clean up the stall horn sound (and hopefully the marker beacon sounds which suffered the same effect.) But at the same time, the doppler effects are maintained as they were. Curt, I am not sure this change is the cause, but there is now no doppler effect for yasim models that have non zero target-z-offset-m's for views 1 through 6. I noticed that the j3 cub, the pittss1c, and the yasim A6M2 all have doppler effects. They all also have no view n=j /view for j=1, 2, ... , 6. But the pa24-250, pa26-161, p51d, and bo105 have no doppler effect. They do have non zero target-z-offset-m in view n=j/view for j=1, 2, ... , 6. I also noticed that if I change the target-z-offset to 0.0, the doppler effect returns but the center of the views is then not what the model author intended. Dave P. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] stall horn sound
On Sun, Nov 30, 2008 at 7:57 PM, Curtis Olson wrote: Hi Dave, I can at least replicate the problem here. I will see if I have any remaining energy this evening after I get the kids to bed. I'm looking at about line #629 in src/Main/main.cxx ... the first thing I would check is if the moving/stationary view point logic is working for these aircraft without doppler effects. I can tell you that current_view-get_view_pos() is moving a non-trivial amount with these aircraft that have the view center position offset. It's almost like the view position is sweeping around by whatever the offset is versus being at a fixed position. So the next step might be to look into the view manager code to see why the view position computation doesn't produce a stationary point when there is a model view offset defined? Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
