Re: [Flightgear-devel] Multi-player servers don't show aircraft icons on Safari
Multi-player servers don't show aircraft icons on Safari - default web browser on Mac OS X. Firefox shows these with no problem. Safari used to show icons when I played last time, maybe Jan. 2nd. I was using mpserver01:5000 from 0.9.10 for Mac OS X. Does anyone know what causes this issue? Assuming you're talking about the online map mpmap01/mpmap02.flightgear.org Can you try it again? I did make some changes to how the aircraft icons are displayed in the last few days. Make sure you try both mpmap01.flightgear.org and mpmap02.flightgear.org Thank you. Pigeon. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multi-player servers don't show aircraft icons on Safari
Hi pigeon, Yes, I'm talking about FlightGear server online map. I tried both mpmap01.flightgear.org and mpmap02.flightgear.org again but nothing has changed so far. Icons (and dots) still don't show up on Safari. Tat On Jan 7, 2007, at 2:09 AM, Pigeon wrote: Multi-player servers don't show aircraft icons on Safari - default web browser on Mac OS X. Firefox shows these with no problem. Safari used to show icons when I played last time, maybe Jan. 2nd. I was using mpserver01:5000 from 0.9.10 for Mac OS X. Does anyone know what causes this issue? Assuming you're talking about the online map mpmap01/ mpmap02.flightgear.org Can you try it again? I did make some changes to how the aircraft icons are displayed in the last few days. Make sure you try both mpmap01.flightgear.org and mpmap02.flightgear.org Thank you. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] pick animation
Hi, On Friday 05 January 2007 21:12, syd wrote: One thing Im unclear on ,reading the documentation , is if the pick animation only works with left clicks. Good enough for toggling properties , but would still need 2 clickable objects for increase /decrease properties .So can a mouse button be chosen with this animation ? You are right! That is not only unclear from the documentation but also form the implementation. I have updated the docs as well as the implementation for the pick animation. You can now include bindings for more than one button with one animation. The buttons are grouped by action tags that contain just the bindings for a single button. So this has changed from the format a few days before! I hope you all do not have to change too much because of that! Greetings Mathias - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] pick animation
syd wrote: Hi all, One thing Im unclear on ,reading the documentation , is if the pick animation only works with left clicks. Good enough for toggling properties , but would still need 2 clickable objects for increase /decrease properties .So can a mouse button be chosen with this animation ? Cheers, Syd First, this animation is a really good idea. I for see a problem though. With the old hotspot code, if you wanted to animate a really small switch, you could make the hotspot a lot bigger, and it would still be easy to hit while you are bouncing around the cockpit in turbulence. Would it be possible to define a sort of fattening factor whereby small objects could respond to clicks nearby to them? Also, will there be a way to highlight these clickable objects like in the panel code (CTRL-C?) Josh - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Alternatives to Terragear pipeline for building
Roberto Inzerillo wrote: Since terrain meshes are based on triangles, I see full flexibility in that (more than what's used today). I guess rectangle blocks (I refer to taxiway/runway/aprons) were choosen in order to get airport layouts quick and easy [...] and certainly for performance reasons as well. Highly detailed airfield layouts using numerous triangles are likely to kill your FlightGear performance. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Alternatives to Terragear pipeline
Roberto Inzerillo wrote: The same goes for lighting, I just want to change the positioning of those light points in space because I don't like the way they are automatically positioned now (specifically on taxiways). I think, concerning taxiway lights for example there is room for improvement without the need to revamp the whole task of creating an airfield. Currently the conversion to OSG is still in process. Once this task is declared as finished, new opportunities arise for better placement of any type of lights. I'm offering tours for interested developers to let them experience how an airfield really looks like at night ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Alternatives to Terragear pipeline
Ralf Gerlich wrote: Of course, TaxiDraw is not limited to creating apt.dat data as Durk's AI extension shows. Maybe we can inspire the involved developers to head for a joint effort of TaxiDraw- and FGSD-development here ;-) The upcoming 'standard' for editing geographic vector data appears to be WFS-T. This is a data interchange method that is best used at smaller areas - because it uses XML - and is based on HTTP, thus allowing operation even over a HTTP proxy. Interested parties are invited to read here: http://docs.codehaus.org/display/GEOSDOC/WFS/ http://udig.refractions.net/confluence/display/GOWS/WFS/ http://en.wikipedia.org/wiki/Geography_Markup_Language/ We're in the progress of offering such service for the Landcover-DB which then allows to edit not only lakes, forest, roads and rivers but we'd offer a repository of elevation contour lines as well. Current status of our geodata repository is here: http://wiki.osgeo.org/index.php/Geodata_Repository#PostGIS_serving_vector_data Have fun, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] location-in-air
On 01/06/2007 04:25 PM, Jon S. Berndt wrote: I'm not sure what you are talking about here. Could you be more descriptive? I'll try! Let's start with some use case analysis: Scenario 1: User wants to practice landings. Using command-line options, the user initializes the system to 4 mile final and 1500 feet above the runway. User lands OK, and wants to try it again. For maximum realism, he should taxi back, take off, and fly the pattern. But for best use of lesson time, it would be nice to relocate to a similar point (at this airport or another) and take it from there. Certainly the user could accomplish this by quitting out of the simulator and going wherever he likes using the command-line options on new invocation of the simulator, but it would be much more elegant to go there /without/ quitting and restarting. For this purpose the simulator provides the location-in-air popup. Scenario 2: Same as above, but practicing instrument approaches. The time savings are even greater, because the distances involved are often greater. The initial approach fix could be 20 or 30 miles from the airport. Scenario 3: The pilot makes a mistake enroute, and would like to back up a few miles and try it again. In this case it is particularly valuable to define the reference point as an offset relative to here i.e. relative to the aircraft's present position. Scenario 4: The pilot is on a long, boring leg, and would like to fast forward a few miles to get closer to a more interesting part of the journey. Note: All such use-case scenarios are black-box descriptions of what is desired. That is, the pilot doesn't care how any of it is implemented internally. OTOH, we now need to take off our pilot hats and put on our developer hats. We need to discuss implementation issues. The location-in-air popup is implemented as follows: It fills in some variables, and then invokes some sort of reset on the FDM. The interface seems to be called presets-commit if I'm reading the xml correctly. All evidence indicates that the function being called was not designed to be used this way, i.e. not to be used in flight and not to be used repeatedly. Instead it was supposed to be used once, during initial startup. There are numerous problems that need to be fixed. I don't much care how they get fixed, including -- defining and implementing a new relocate function, or -- robustifying the old reset or preset function so that it can handle a wider range of uses. -- or whatever. Specific problems include: 1) If the property /sim/presets/trim is true when presets-commmit is called, it attempts to trim the aircraft. I'm not sure what is the objective of such trimming, but by its own standards the procedure often fails. It prints error messages on the console complaining about various kinds of failures; see appendix below. My observations suggest that repeated calls to the presets-commit progressively increase the probability of failure. That is, the failure /probability per call/ is increasing. 2) Even if the trim function succeeds, it messes with the throttle settings. This is weird and undesirable in situations (such as mine) where there is a hardware throttle, because it creates a conflict between where the FDM thinks the throttle is and where the hardware throttle is. 3) One particularly weird thing is the behavior of the offset-azimuth and offset-distance properties. My observations indicate that they allow me to apply an offset relative to the reference point /if/ the reference point is an airport, VOR, or NDB ... but, strangely, not if the reference point is a lat/lon. In the latter case, it just relocates to the lat/lon and ignores the offset. This seems like a bug to me. It is significant, because relocating relative to here occurs in many use-cases, and is implemented in terms of the lat/lon of the present position. 4) The function now being called turns off the magnetos. This is clearly not desired behavior if all I'm trying to do is relocate. This is a low-priority bug, because I can work around it by saving and restoring the magneto settings. 5) The function now being called zeros the settings for aileron trim, elevator trim, and rudder trim. Again, this is clearly not desired behavior. First, which version of JSBSim are you using? I don't exactly know. I don't know how to get fgfs to print a version number. The fgfs binary has a date of 2006-05-17 if that means anything to you. I think this is just whatever one gets by asking Debian-etch to install fgfs. FWIW I am using the /data/ from CVS. From what I understand, Erik just put a new version of JSBSim in FlightGear CVS. I guarantee that I'm not using the CVS version. I couldn't get it to compile. Various people have sent me bunches of patches, but it still won't compile. Second, The trim function works good in JSBSim by itself, and I thought it had been working with FlightGear, too. So, no,
Re: [Flightgear-devel] pick animation
On Sun, 2007-01-07 at 09:51 -0500, Josh Babcock wrote: First, this animation is a really good idea. I've spent the better part of the weekend adding instruments to my F4E, this code ROCKS! I for see a problem though. With the old hotspot code, if you wanted to animate a really small switch, you could make the hotspot a lot bigger, and it would still be easy to hit while you are bouncing around the cockpit in turbulence. Would it be possible to define a sort of fattening factor whereby small objects could respond to clicks nearby to them? One solution is to make the area around the spot a separate model and make that clickable, too. Also, will there be a way to highlight these clickable objects like in the panel code (CTRL-C?) This already works... ctrl-c highlights the clickable object's wireframe in yellow. Caveat: I last pulled from CVS on Friday... Ron - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] location-in-air
John Denker wrote: [... reset function ...] All evidence indicates that the function being called was not designed to be used this way, i.e. not to be used in flight and not to be used repeatedly. Instead it was supposed to be used once, during initial startup. John, actually, what you're looking for is a routine that allows you to dump the whole property tree at runtime into a file and allow re-loading this as a preset. In order not to break current behaviour it would be necessary to compile a 'standard-preset' file that would be loaded upon reset unless otherwise defined. Correct ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Alternatives to Terragear pipeline
Hi, Martin Spott wrote: Ralf Gerlich wrote: Of course, TaxiDraw is not limited to creating apt.dat data as Durk's AI extension shows. Maybe we can inspire the involved developers to head for a joint effort of TaxiDraw- and FGSD-development here ;-) [SNIP] We're in the progress of offering such service for the Landcover-DB which then allows to edit not only lakes, forest, roads and rivers but we'd offer a repository of elevation contour lines as well. Current status of our geodata repository is here: I didn't have this in mind, but it fits the concept I had in mind. Especially the elevation contour data might be interesting for people wanting to modify the elevation setup in their airports ;-) Oh, and in the redesign of the TaxiDraw infrastructure I laid much weight on the requirement of the infrastructure being reusable. So if someone has an idea on map editing that doesn't fit the concept of TaxiDraw (and possibly doesn't operate in the mapping context of an airport) can use the basic TaxiDraw infrastructure for setting up a mapping application based on wxWidgets quite fast. Cheers, Ralf - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] location-in-air
On 01/07/2007 12:28 PM, Martin Spott wrote: John, actually, what you're looking for is a routine that allows you to dump the whole property tree at runtime into a file and allow re-loading this as a preset. In order not to break current behaviour it would be necessary to compile a 'standard-preset' file that would be loaded upon reset unless otherwise defined. Correct ? Well, no, that isn't really what I was looking for. Indeed if I had to put that on the list of things I'd like to have, it wouldn't rank very high ... partly because the pilot would need to fly to a place before doing the dump. For my purposes (and I suspect a lot of other purposes besides), is much more useful to be able to warp to some improvised place, without ever having been there before. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PRE_OSG cvs BUG in VSI with code fix
On Sunday 07 January 2007 17:34, gh.robin wrote: On Sun 7 January 2007 18:20, Martin Spott wrote: Nick Warne wrote: There is a typo in: src/Instrumentation/vertical_speed_indicator.cxx line 17: _static_pressure(node-getStringValue(static-pressure, /Systems/static/pressure-inhg)) should be of course: _static_pressure(node-getStringValue(static-pressure, /systems/static/pressure-inhg)) This affects CVS head as well; would someone consider applying the respective change ? Martin. You must first check it , because the existing code is working right with /Systems/static/pressure-inhg Well, on Linux at least with that line I got two 'systems' directories in the property tree - one called /Systems/ with one item, the other called /systems/ with a host of data. But I am on full osg build now, so can't test what I got at the time. Nick - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PRE_OSG cvs BUG in VSI with code fix
On Sun 7 January 2007 18:42, Nick Warne wrote: You must first check it , because the existing code is working right with /Systems/static/pressure-inhg Well, on Linux at least with that line I got two 'systems' directories in the property tree - one called /Systems/ with one item, the other called /systems/ with a host of data. But I am on full osg build now, so can't test what I got at the time. Nick Anyway, it is not a good idea to destroy stuff which were improved in the past. Would no it be better to wait for a complete achievement of that huge migration from PLIB to OSG (thanks to Mathias) before to try to modify the existing working codes. As i said before we have lost the autopilot , and i guess that OSG has nothing to do with these bugs. -- Gérard - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Vulcan Patch
Buchanan, Stuart wrote:
Note for committer: texture3.rgb is now redundant and can be removed from
CVS.
jive: 19:04:41 ~/SCM/FlightGear/data/Aircraft find . -name texture3.rgb
./X15/Models/texture3.rgb
jive: 19:05:45 ~/SCM/FlightGear/data/Aircraft/vulcanb2 find . -type f -exec
grep -l texture3.rgb {} \;
[... empty ...]
???
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PRE_OSG cvs BUG in VSI with code fix
gh.robin wrote: On Sun 7 January 2007 18:20, Martin Spott wrote: Nick Warne wrote: There is a typo in: src/Instrumentation/vertical_speed_indicator.cxx line 17: _static_pressure(node-getStringValue(static-pressure, /Systems/static/pressure-inhg)) should be of course: _static_pressure(node-getStringValue(static-pressure, /systems/static/pressure-inhg)) This affects CVS head as well; would someone consider applying the respective change ? You must first check it , because the existing code is working right with /Systems/static/pressure-inhg Let me guess, you're running this on Windows. Right ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] compilation pb: error: 'const class osg::Viewport' has no member named 'getViewport'
Sébastien, I posted a compilation fix yesterday, see http://sourceforge.net/mailarchive/message.php?msg_id=37837809 bye, Manuel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PRE_OSG cvs BUG in VSI with code fix
On Sun 7 January 2007 19:09, Martin Spott wrote: gh.robin wrote: On Sun 7 January 2007 18:20, Martin Spott wrote: Nick Warne wrote: There is a typo in: src/Instrumentation/vertical_speed_indicator.cxx line 17: _static_pressure(node-getStringValue(static-pressure, /Systems/static/pressure-inhg)) should be of course: _static_pressure(node-getStringValue(static-pressure, /systems/static/pressure-inhg)) This affects CVS head as well; would someone consider applying the respective change ? You must first check it , because the existing code is working right with /Systems/static/pressure-inhg Let me guess, you're running this on Windows. Right ? Martin. Windows what is that i don't know, I ever worked with LINUX went it cames up :) -- Gérard - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PRE_OSG cvs BUG in VSI with code fix
On Sun 7 January 2007 19:13, gh.robin wrote: On Sun 7 January 2007 19:09, Martin Spott wrote: gh.robin wrote: On Sun 7 January 2007 18:20, Martin Spott wrote: Nick Warne wrote: There is a typo in: src/Instrumentation/vertical_speed_indicator.cxx line 17: _static_pressure(node-getStringValue(static-pressure, /Systems/static/pressure-inhg)) should be of course: _static_pressure(node-getStringValue(static-pressure, /systems/static/pressure-inhg)) This affects CVS head as well; would someone consider applying the respective change ? You must first check it , because the existing code is working right with /Systems/static/pressure-inhg Let me guess, you're running this on Windows. Right ? Martin. Windows what is that i don't know, I ever worked with LINUX went it cames up :) And if you don't trust me, when i say its working, look at this http://perso.orange.fr/GRTux/pressure-inhg.jpg -- Gérard - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] location-in-air
John Denker wrote: [...] For my purposes (and I suspect a lot of other purposes besides), is much more useful to be able to warp to some improvised place, without ever having been there before. Without ever having been there before I'd say you'll never know in which state the aircraft is supposed to be in, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft maintainers sought
Thanks for all the nice words folks, and to Josh and Alexis for taking on the Canberra and A-10. I'll still be following the lists and I'll be happy to answer any questions about any of the aircraft I've worked on and try to explain what my line of reasoning might have been behind some of the FDMs and what I might have been trying to do in some of the control systems stuff. LeeE - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Time lag in Multiplayer: question, was Re: Aerotow and winch patch
Hi, On Sunday 07 January 2007 14:38, Maik Justus wrote: I've programmed a moving mean of calculated lags. Have to check it out now. I have not tried. But had a quick look at the code. You are talking about the _towLength value that appears to be used for the tow tension instead of the real current distance. That is just some kind of smoothed aircraft distance ... Ok, the problem to solve in this case is to approximate a nearly constant function of time. Smoothing that appears to be a good idea. An other thing: Would it be possible to factor out code that is independent of the FDM into FGInterface so that we do not have a YASim only api? For example the code that searches for an other aircraft to connect your row to is independent of YASim. Also once we have found that object we are towed to, FGInterface may provide the current position and velocity preferably both in the wgs84 system to the FDM implementation. YASim will then work through that interface. That way other FDM's will have a chance to catch that same interface up. Greetings Mathias - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot is no longer working within FG osg branch
On Sunday 07 January 2007 13:12, gh.robin wrote: Hello, Between the 13 December 2006 and last night 07 January , the autopilot has vanished With my previous built of Flightgear osg branch 13-12-2006 dated i was still able to run autopilot the heading and altitude where nicely taken , and the aircraft could fly correctly ( everything usual and normal), the waypoint was working. Since last night after built of Flightgear these functions are out, in the best case, if i am lucky, the aircraft stay at an altiude (any altiude) and fly on a large circle. If i am not lucky the aircraft crash. Is there any new function , or is it a bug ? Regards -- Gérard I experienced similar problems a few days ago - some of the AP controllers seemed to be working from start-up but others didn't. Re-setting the AP controllers via the debug menu appeared to kick them into life after start-up. I also had problems with some AP controllers seeming not to work after I removed other unrelated redundant controllers but didn't have enough time to look further into it or establish any consistency. LeeE - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] location-in-air
On 01/07/2007 01:25 PM, Martin Spott wrote: [...] For my purposes (and I suspect a lot of other purposes besides), is much more useful to be able to warp to some improvised place, without ever having been there before. Without ever having been there before I'd say you'll never know in which state the aircraft is supposed to be in, Well, I'd say differently, based on a lot of recent experience doing it, using my new version of the locate-in-air popup. Physics says it ought to work: I start out (on the ground or in the air) with a reasonable power setting and reasonable trim settings, I can give myself a new altitude, a new XY position, a new heading, and/or a new airspeed ... and it just works. Try it sometime. The garbage-in-garbage-out principle applies: If you relocate yourself into the air before starting the engines, you'll have a few moments of excitement dealing with the consequences. Similarly, if you dictate a new airspeed that is inconsistent with your elevator trim setting, you'll get some additional excitement. It should be particularly obvious that air-to-air relocation should just work. Air here looks a lot like air there. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Time lag in Multiplayer: question, was Re: Aerotow and winch patch
Hi, Mathias Fröhlich schrieb am 07.01.2007 19:44: Hi, On Sunday 07 January 2007 14:38, Maik Justus wrote: I've programmed a moving mean of calculated lags. Have to check it out now. I have not tried. But had a quick look at the code. You are talking about the _towLength value that appears to be used for the tow tension instead of the real current distance. That is just some kind of smoothed aircraft distance ... yes, exactly. (this moving mean calculation is not in the patch I sent, it's just in my local version). I am fighting now with the performance of my notebook running two instances of flightgear Ok, the problem to solve in this case is to approximate a nearly constant function of time. Smoothing that appears to be a good idea. An other thing: Would it be possible to factor out code that is independent of the FDM into FGInterface so that we do not have a YASim only api? For example the code that searches for an other aircraft to connect your row to is independent of YASim. Also once we have found that object we are towed to, FGInterface may provide the current position and velocity preferably both in the wgs84 system to the FDM implementation. YASim will then work through that interface. I think, that's the way to go. We/I first should test the YASim-patch. If it works I will try to extract the FDM-independent code (I need a hint, where to place it then ;-) ). That way other FDM's will have a chance to catch that same interface up. Greetings Mathias Thanks, Maik - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PRE_OSG cvs BUG in VSI with code fix
On Sunday 07 January 2007 19:44, Nick Warne wrote: On Sunday 07 January 2007 18:40, Roy Vegard Ovesen wrote: On Sunday 07 January 2007 19:25, gh.robin wrote: And if you don't trust me, when i say its working, look at this http://perso.orange.fr/GRTux/pressure-inhg.jpg Nick is right, /Systems/... _is_ a typo. The reason why it is working for Gérard is because at runtime the default /Systems/... is overridden by what is in his intrumentation configuration file (/systems/...). Also something to do with the aircraft xml cfg files using static-port which uses something else, I believe. The static-port tag in instrumentation configuration files is no longer used. It has been replaced with the static-pressure tag where one can specify the complete path to the property that one wish to use. I hunted down all the instrumentation configuration files and replaced before sending for committ to CVS, but I can not guarante that I found them all. -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PRE_OSG cvs BUG in VSI with code fix
On Sun 7 January 2007 19:40, Roy Vegard Ovesen wrote: On Sunday 07 January 2007 19:25, gh.robin wrote: And if you don't trust me, when i say its working, look at this http://perso.orange.fr/GRTux/pressure-inhg.jpg Nick is right, /Systems/... _is_ a typo. The reason why it is working for Gérard is because at runtime the default /Systems/... is overridden by what is in his intrumentation configuration file (/systems/...). I am glad to learn that it is possible to have a Cockpit with working instruments , without any instrumentation configuration file, and possible to read the value on the VSI instrument. I will spare a lot of time during the cockpit development. Which explain probably that it was possible to conclude the VSI did not worked because of that Typo. -- Gérard - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] patch to compile flightgear against osg HEAD
Hi Manuel,
On Saturday 06 January 2007 14:33, Manuel Massing wrote:
attached is a tiny patch for src/Model/panelnode.{cxx,hxx} to make
flightgear compile against osg HEAD, apparently the interface to
osg::Viewport has changed slightly.
Might spare a few seconds to those who track osg HEAD.
I have checked in a small patch very similar to yours that should hopefully
compile with osg HEAD and the patched 1.2 release.
Tell me if it does not work with OSG HEAD.
Greetings
Mathias
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PRE_OSG cvs BUG in VSI with code fix
On Sunday 07 January 2007 19:25, gh.robin wrote: You must first check it , because the existing code is working right with /Systems/static/pressure-inhg And if you don't trust me, when i say its working, look at this http://perso.orange.fr/GRTux/pressure-inhg.jpg Ok! Now I'm just confused. Gérard is trying to prove that /Systems/static/pressure-inhg is working by sending a screenshot showing /systems/static/pressure-inhg. Nick, how did you get it to fall back to /Systems/...? Did you use a custom instrumentation config file, or did you forget to also update the base package (data) from CVS? -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PRE_OSG cvs BUG in VSI with code fix
On Sunday 07 January 2007 20:13, gh.robin wrote: On Sun 7 January 2007 19:40, Roy Vegard Ovesen wrote: On Sunday 07 January 2007 19:25, gh.robin wrote: And if you don't trust me, when i say its working, look at this http://perso.orange.fr/GRTux/pressure-inhg.jpg Nick is right, /Systems/... _is_ a typo. Can someone with CVS write access please fix this, thanks. The reason why it is working for Gérard is because at runtime the default /Systems/... is overridden by what is in his intrumentation configuration file (/systems/...). I am glad to learn that it is possible to have a Cockpit with working instruments , without any instrumentation configuration file, and possible to read the value on the VSI instrument. I will spare a lot of time during the cockpit development. If you don't specify any instrumentation config file in your *-set.xml file then it will of course use what is in preferences.xml. That is data/Aircraft/Generic/generic-instrumentation.xml. The same is true for systems config file. -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PRE_OSG cvs BUG in VSI with code fix
On Sunday 07 January 2007 19:51, Roy Vegard Ovesen wrote: On Sunday 07 January 2007 19:25, gh.robin wrote: You must first check it , because the existing code is working right with /Systems/static/pressure-inhg And if you don't trust me, when i say its working, look at this http://perso.orange.fr/GRTux/pressure-inhg.jpg Ok! Now I'm just confused. Gérard is trying to prove that /Systems/static/pressure-inhg is working by sending a screenshot showing /systems/static/pressure-inhg. Nick, how did you get it to fall back to /Systems/...? Did you use a custom instrumentation config file, or did you forget to also update the base package (data) from CVS? Heh. It is _very_ complicated and the following is from memory as I forget exactly what I was doing/sussing. Basically I made a mess up when I was building/installing. I got my 'plib' build and 'osg' build data's messed up. When I used the Spitfire model I noticed the VSI wasn't working. Investigating then showed I had a '/Systems/' and a '/systems/ branch in the properties. The '/System/' branch _only_ held the value 'pressure-inhg' but it was null. I then saw I also had a /systems/ branch that also had 'pressure-inhg' with a value (and lots of other data too). Hence then how I came to find the typo in the source code. Speaking in IRC to Vivian, it turned out the Spitfire I was using wasn't the latest... that's when I found out I had all my data files and stuff all mixed up. Cleaning this up, the model now does not use that code part, hence why it works with the /Systems/. I wish I could remember what the xml file was that used it. Nick - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] compilation pb: error: 'const class osg::Viewport' has no member named 'getViewport'
thank you very much Manuel, it compiles perfectly now. regards Manuel Massing a écrit : Sébastien, I posted a compilation fix yesterday, see http://sourceforge.net/mailarchive/message.php?msg_id=37837809 bye, Manuel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] memory leak
My version of fgfs has a rather large memory leak. If I leave the thing parked after a flight, brakes on, simulator paused, it will gobble up about 3 gigabytes of virtual memory overnight. (In contrast, it's only a little over 500 meg after a few minutes of flight.) I'm running the version of fgfs that is bundled with the current Debian etch distribution. The fgfs binary is dated May 17 2006 if that means anything. I'm using it with the /data/ from cvs. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
