Re: [Flightgear-devel] flight control and trim position popup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Denker wrote: Let me also point out that the word gremlin is in the dictionary. Its primary meaning explains exactly the purpose of gremlins.nas. Please consider, that not by far not all FG contributors are native English speakers and thus may not be familiar with every possible meaning of such words. It for sure looked strange to me and neither Wikipedia, nor the English-German dictionary on http://dict.leo.org gave any indication, that it's a proper word for this purpose. I don't say, that I don't believe you. But I think it's a good rule of thumb to not consider anything a personal attack unless proven. It may as well be a simple language problem. That said, I like the name ;) Nine -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGi0h71QuEJQQMVrgRAhgAAJwJA15AbH+HcGrs4ALnpbFfXDZ9MwCeLQx6 ugwHnmDj2sK6cR3cnjOjGH0= =4oWN -END PGP SIGNATURE- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flight control and trim position popup
On 07/03/2007 04:28 AM, Vivian Meazza wrote: Remember: P 6 - Piss Poor Peer-review Prevents Proper Performance I agree! IMHO a peer-review that snipes at int ii as opposed to int i -- to the exclusion of any discussion of actual features that pilots can use -- is pretty poor. IMHO it is a mistake even to respond to such sniping; responding gives the sniping an appearance of importance it does not deserve, and encourages bad behavior. So, ignoring various obviously-false accusations, here's where we stand regarding the flight-control popup: -- There was one bona-fide misunderstanding, which has been cleared up. -- AFAICT, there remain no objections of any significance. -- The fact remains that the axis polarity in FG is inconsistent with all the usual conventions. This can be seen in most (perhaps all) joystick configuration files, where there is a factor of -1 applied to the pitch axis, but not to the roll and yaw axes. This inconsistency would be seen again in the flight-control popup, except that I solved it via the aforementioned flipper patch. http://www.av8n.com/fly/fgfs/flipper.diff (Note that this new flipper property could be used to simplify the joystick configurations if anybody wanted to.) -- As has been previously stated repeatedly, this popup is intended to serve pilots while flying the aircraft. It is needed as a workaround because appallingly many of the aircraft in the FG fleet still lack usable trim indicators. -- Its intended purpose was not solely for debugging joysticks. It is not optimized for that purpose. A popup for that purpose would differ in several ways. If somebody wants to use the flight control popup as the starting point for a joystick debugging popup, that's a bonus. The possibility of such a bonus is certainly not a valid objection to the existing pilot-oriented popup. I hope that overall, most FG-related time is spent piloting FG as opposed to debugging it. (If not, this project is more screwed up than I thought.) Developers should not assume that the world revolves around development; users i.e. pilots ought to count for something. If some developer, for development purposes, wants to increase the number of digits in the display, I parameterized the format so that changing it is a simple one-character edit. http://www.av8n.com/fly/fgfs/flight-control.diff I hope that a one-character edit is not too much of a burden. Bottom line: Does anybody have any suggestions and/or questions about this work? - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flight control and trim position popup
Am Mittwoch 04 Juli 2007 15:59 schrieb John Denker: If some developer, for development purposes, wants to increase the number of digits in the display, I parameterized the format so that changing it is a simple one-character edit. http://www.av8n.com/fly/fgfs/flight-control.diff I hope that a one-character edit is not too much of a burden. I think this (changing code for parameterization) is quite dangerous, as it easily slips through in a commit, setting higher/lower precision for all on next cvs update :-) Probably it is possible to control precision via a property in the tree. Then it could be set in the conf file (.fgfsrc). Just a thought. Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flight control and trim position popup
* John Denker -- Wednesday 04 July 2007: Bottom line: Does anybody have any suggestions and/or questions about this work? Well, there are still two objections concerning the submissions: - the name gremlins.nas. But this could certainly be changed by whoever commits this. I suggested failure.nas. The function name gremulate() isn't pretty, either, especially together with a gremlins namespace (gremlins.gremulate() ?), but it's not a real problem. - the dialogs use hardcoded fixed sizes and positions, and don't use the layouter. This makes them unable to adapt to different gui styles. Would fixing that be a problem? Someone else could do it, too, of course. (As I said: I don't find the nnn/ttt variables reasonable, but I also made clear that this was *not* an objection. And I couldn't know that this technique is used by skilled programmers, sorry.) m. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flight control and trim position popup
* John Denker -- Wednesday 04 July 2007: Well, there are still two objections concerning the submissions: [- fixed size and positions of dialogs] - the name gremlins.nas. But this could certainly be changed by whoever commits this. I suggested failure.nas. The function name gremulate() isn't pretty, either, especially together with a gremlins namespace (gremlins.gremulate() ?), but it's not a real problem. This has got absolutely positively nothing to do with the flight control and trim position popup. Yes, well observed. But the first problem concerns both submissions, and to reduce noise on the list I combined that. Didn't work out. :-) m. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flight control and trim position popup
On 07/04/2007 10:49 AM, Melchior FRANZ wrote: Well, there are still two objections concerning the submissions: - the name gremlins.nas. But this could certainly be changed by whoever commits this. I suggested failure.nas. The function name gremulate() isn't pretty, either, especially together with a gremlins namespace (gremlins.gremulate() ?), but it's not a real problem. This has got absolutely positively nothing to do with the flight control and trim position popup. It is not a valid objection to the flight control and trim position popup, which is the subject of this thread. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flight control and trim position popup
--- Melchior FRANZ wrote: * John Denker -- Wednesday 04 July 2007: Well, there are still two objections concerning the submissions: [- fixed size and positions of dialogs] snip But the first problem concerns both submissions, and to reduce noise on the list I combined that. Didn't work out. :-) Until you mentioned it, I thought all these comments only applied to the flight control popup so I wasn't paying much attention. I think perhaps you were being too efficient ;) Could you explain further regarding the fixed size of the dialogs? I used the table layout for both the system-failure and instrument-failure dialogs, with the width and height defined to set appropriate padding. Is there a better way to do this that I'm not aware of (or have forgotten)? I tested both dialogs with both GUI styles, and they looked acceptable to me. Changing the name to failures.nas, and gremulate to, say, generate sounds fine to me. While I think the word gremlins is appropriate in this context, I can appreciate that for non fluent English speakers it might lead to confusion. -Stuart ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] How to apply different texturing to the terrain mesh?
Hello together. Now that I've found that the FlightGear source code does not have to be a book with seven seals for me and I was successfull with implementing my first, although small and simple, change to it, I got the idea to try a somewhat bigger modification to the program: I'd like to do some experiments with displaying ground features like roads, rivers and land usage completely through (automatically generated) textures instead of the current material/triangle-based approach. I think that drawing these features totally indepentent of the underlying triangulation has several great advantages, with the following two being the most important ones: - It would offer the possibility of drawing more details and generally more organic ground features than it would ever be possible with the triangle/materials approach with its inevitable hard edges and performance limitations (no way to render zillions of triangles for all the smallest details) - It would uncouple the processes of generating and drawing all the flat ground features from the processes of generating and displaying the terrain mesh. This would allow us to modify and extend the complexity of displayed flat ground stuff completely without having to edit or regenerate the terrain mesh. New roads or other things could easily be added by modifying a roads vector dataset and regenerate the responsible ground texture tiles (or even by painting the road onto them with a graphics program). I know and admit that this approach also may have some quite big disadvantages, primarily performance problems because of limited hardware resources, and of course the feared blurry ground at low altitudes effect. I have no idea if I will ever get this to work (with acceptable results), I have no idea if it will be better than the current solution (and even accepted as such by the community), but anyway - I would just like to try it. Just for my own fun and interest, if you don't like it. Now why I'm writing this sermon: It would be great if someone who has good knowledge of these parts of FlightGear which are critical for this experiment could support me with answers to some questions which will surely arise. This first one, to which the definition of the whole challenge can be reduced as for now, is nothing more or less than the following: How can I implement an override for the current way of how the terrain triangles are textured, which allows me to look at each single triangle, identified by the world coordinates of its corner vertices, and map a defined part of an arbitrary texture file onto it? Like saying, I have an image file which represents a certain part of the world with four corners at specific lat/lon coordinates, and now I want FlightGear to render this image onto the ground at exactly this place in the virtual world. I hope my explaination can be understood and I'm looking forward to some helpful replies :) With best regards, Sebastian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh?
Hi, Hmmm sounds like the flat textures which MSFS has... I like the way it is, because with the material you have some informations about bumbiness and so on... So much as I know, someone is working on the possibility to change the terrain easily ( I think Frederic Bouvier ) So I'm not sure about if this is a good idea... Greetings HHS --- Sebastian Bechtold [EMAIL PROTECTED] schrieb: Hello together. Now that I've found that the FlightGear source code does not have to be a book with seven seals for me and I was successfull with implementing my first, although small and simple, change to it, I got the idea to try a somewhat bigger modification to the program: I'd like to do some experiments with displaying ground features like roads, rivers and land usage completely through (automatically generated) textures instead of the current material/triangle-based approach. I think that drawing these features totally indepentent of the underlying triangulation has several great advantages, with the following two being the most important ones: - It would offer the possibility of drawing more details and generally more organic ground features than it would ever be possible with the triangle/materials approach with its inevitable hard edges and performance limitations (no way to render zillions of triangles for all the smallest details) - It would uncouple the processes of generating and drawing all the flat ground features from the processes of generating and displaying the terrain mesh. This would allow us to modify and extend the complexity of displayed flat ground stuff completely without having to edit or regenerate the terrain mesh. New roads or other things could easily be added by modifying a roads vector dataset and regenerate the responsible ground texture tiles (or even by painting the road onto them with a graphics program). I know and admit that this approach also may have some quite big disadvantages, primarily performance problems because of limited hardware resources, and of course the feared blurry ground at low altitudes effect. I have no idea if I will ever get this to work (with acceptable results), I have no idea if it will be better than the current solution (and even accepted as such by the community), but anyway - I would just like to try it. Just for my own fun and interest, if you don't like it. Now why I'm writing this sermon: It would be great if someone who has good knowledge of these parts of FlightGear which are critical for this experiment could support me with answers to some questions which will surely arise. This first one, to which the definition of the whole challenge can be reduced as for now, is nothing more or less than the following: How can I implement an override for the current way of how the terrain triangles are textured, which allows me to look at each single triangle, identified by the world coordinates of its corner vertices, and map a defined part of an arbitrary texture file onto it? Like saying, I have an image file which represents a certain part of the world with four corners at specific lat/lon coordinates, and now I want FlightGear to render this image onto the ground at exactly this place in the virtual world. I hope my explaination can be understood and I'm looking forward to some helpful replies :) With best regards, Sebastian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel __ BE A BETTER FRAGESTELLER: Jetzt Frage stellen und einen von 44 iPods gewinnen! www.yahoo.de/clever - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random instrument failures and altimeter gremlins patch
On Tuesday 03 July 2007 22:58, Melchior FRANZ wrote:
* Stuart Buchanan -- Tuesday 03 July 2007:
The included XML files replace those in the gui/dialogs directory, while
gremlins.nas should be put in the Nasal directory.
gremlins.nas? Please not funny names in $FG_ROOT/Nasal/. These
are code files, and so far all of them were called after their purpose.
This makes it easier for all to see what they are about.
What I don't really understand is why local variables need to be ii and
nnn. What's wrong with just i and n, like everyone else uses? Or is
exactly *that* the problem?
for (ii = 0; ii 5; ii+=1){
...
nnn = props.globals.getNode(feat ~ /serviceable, 1);
if (nnn.getValue() == nil) {
nnn.setBoolValue(1);
Or is nnn an acronym for something?
m.
Is it really worth making an issue over two and three character local variable
names?
LeeE
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh?
Hi, But I forgot a wish: I would love to see, if we could change and do individuals paintings of the ground of airports - all the lines and markings. Maybe that could be something... Greetings HHS --- Sebastian Bechtold [EMAIL PROTECTED] schrieb: Hello together. Now that I've found that the FlightGear source code does not have to be a book with seven seals for me and I was successfull with implementing my first, although small and simple, change to it, I got the idea to try a somewhat bigger modification to the program: I'd like to do some experiments with displaying ground features like roads, rivers and land usage completely through (automatically generated) textures instead of the current material/triangle-based approach. I think that drawing these features totally indepentent of the underlying triangulation has several great advantages, with the following two being the most important ones: - It would offer the possibility of drawing more details and generally more organic ground features than it would ever be possible with the triangle/materials approach with its inevitable hard edges and performance limitations (no way to render zillions of triangles for all the smallest details) - It would uncouple the processes of generating and drawing all the flat ground features from the processes of generating and displaying the terrain mesh. This would allow us to modify and extend the complexity of displayed flat ground stuff completely without having to edit or regenerate the terrain mesh. New roads or other things could easily be added by modifying a roads vector dataset and regenerate the responsible ground texture tiles (or even by painting the road onto them with a graphics program). I know and admit that this approach also may have some quite big disadvantages, primarily performance problems because of limited hardware resources, and of course the feared blurry ground at low altitudes effect. I have no idea if I will ever get this to work (with acceptable results), I have no idea if it will be better than the current solution (and even accepted as such by the community), but anyway - I would just like to try it. Just for my own fun and interest, if you don't like it. Now why I'm writing this sermon: It would be great if someone who has good knowledge of these parts of FlightGear which are critical for this experiment could support me with answers to some questions which will surely arise. This first one, to which the definition of the whole challenge can be reduced as for now, is nothing more or less than the following: How can I implement an override for the current way of how the terrain triangles are textured, which allows me to look at each single triangle, identified by the world coordinates of its corner vertices, and map a defined part of an arbitrary texture file onto it? Like saying, I have an image file which represents a certain part of the world with four corners at specific lat/lon coordinates, and now I want FlightGear to render this image onto the ground at exactly this place in the virtual world. I hope my explaination can be understood and I'm looking forward to some helpful replies :) With best regards, Sebastian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel __ Wissenswertes für Bastler und Hobby Handwerker. BE A BETTER HEIMWERKER! www.yahoo.de/clever - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flight control and trim position popup
FWIW, when flying I have often wanted to see trim indication so I think the popup is valuable. I don't know whether there should be more trim indication in plane cockpits or (because of the already-cramped screen) if a popup is a better approach, but I like the always-available popup idea. Numbers are fine by me; although I won't know at first whether 0.05 or 0.45 will kill me, I will quickly learn some kind of semantics after a few tries. A graphical indication (maybe an addition to the HUD) is another idea - perhaps more intuitive but likely harder to code. This is here now. On 7/3/07, John Denker [EMAIL PROTECTED] wrote: This implements a popup to show the position of the flight controls and trim. This is a workaround for the many aircraft that still lack usable trim indicators, cowl flap indicators, et cetera. TRIM SET is a checklist item in every aircraft I've seen; it's kinda hard to have a realistic flight when there's no trim indicator. Proper functioning of the popup is dependent on the recent validate_format and flight control polarity patches to the source tree. http://www.av8n.com/fly/fgfs/flight-control.diff - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Hans Fugal Fugal Computing - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh?
Am Mittwoch 04 Juli 2007 19:38 schrieb Heiko Schulz: Hi, But I forgot a wish: I would love to see, if we could change and do individuals paintings of the ground of airports - all the lines and markings. Maybe that could be something... AFAIK Ralf Gerlich has done some research in that direction, as the new X-Plane apt.dat format codes this information. But he is totally overburdened with PhD, TaxiDraw, TerraGear, name some 10 projects more work... :-) Probably check back with him for more info. Also see the preliminary results at http://www.custom-scenery.org/ , especially http://www.custom-scenery.org/Research-Deve.274.0.html Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] spanning multiple columns in gui layout
Here's a creeping feature that would be useful, and shouldn't be too hard to implement: Here's the scenario: Suppose you have a nice table with rows and columns. Most of the rows have many narrow columns, but one or two rows have a lesser number of wider columns. The existing layout manager has no idea how to handle this AFAICT. If you just express the wide element as: text row7/row col3/col labelfoofoofoofoobarbarbarbar/label /text it will distort the width of its column, and distort the width of the entire table. You might be able to work around it by hand, e.g. text halignright/halign row7/row col3/col labelfoofoofoofoo/label /text text halignleft/halign row7/row col4/col labelbarbarbarbar/label /text but that doesn't look exactly right, and doesn't work for properties (as opposed to static labels). And it doesn't generalize well to more than two columns. And it doesn't work for most halignments. There is a simple way to express what is wanted, namely: text row7/row col3/col col5/col labelfoofoofoofoobarbarbarbar/label /text which means that the element is supposed to span from column 3 to column 5 inclusive. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random instrument failures and altimeter gremlins patch
* leee -- Wednesday 04 July 2007: Is it really worth making an issue over two and three character local variable names? My comments weren't made as a random list subscriber, but as someone who was about to commit the stuff, and would have liked some things changed first. And yes, that also concerns coding style. The nnn/ttt/... notation is ugly. I said so, and that's it. These were only *my* prerequisites, not general, official ones. If mine aren't met, then I'm just not available for committing. The one who commits code is, after all, responsible for its quality, not the one who wrote it. My objections were dismissed by the submitter, so my involvement in this matter is hereby finished. There are 20 other people with commit permissions. They should have some fun, too. There are surely some who don't have any conditions. Dump into aircraft directories whatever you like. Just keep the common space clean, please. :-} m. -- You don't seem to understand what being a maintainer means. It means saying no to crap. -- Linus TORVALDS - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
