Re: [Flightgear-devel] Default Aircraft Candidates
On Mon, Feb 21, 2011 at 7:41 PM, Jack Mermod wrote: > Are you telling me this is realistic too? No, it is notso stop flying like that... :-P Really, what is with this recent trend of bashing quite rudely on the 777? And the usual "evidence" is stuff like that...flying the aircraft completely unrealistically and outside of any normal and tested flight envelope and complaining vaguely that the FDM somehow is unrealistic because of that. The 777 FDM may not be perfect (what sim aircraft is?), but I think you'll find if you fly the aircraft in a manner approaching something normal and realistic it is not nearly so bad as some people keep trying to make it out to be. syd adams wrote: > Reminded me of this video ... it IS a 757 , but still the performance > is amazing ... > http://www.youtube.com/watch?v=_vJliayH6co Now that is what I call a go around... :-) cheers! --Jacob -- Index, Search & Analyze Logs and other IT data in Real-Time with Splunk Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. Free Software Download: http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flight recorder / replay system
It would be wonderful if replay data could be saved and loaded to/from a file rather than only buffered to memory (with decreasing resolution) temporarily. The ability to save and reload (and share) replays would be extremely useful for so many things such as flight training to check student performance of flight exercises, research, testing, virtual airlines checking/verifying flights, contests, etc, etc. A proper configurable replay system with the ability to save and load would be a HUGE feature for flightgear. I know you said you don't plan on changing the buffering methods, but while your in there...if you feel inspired ;) cheers -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flight recorder / replay system
On Sat, Oct 1, 2011 at 5:58 PM, ThorstenB wrote: > Also, the option of taking over flight controls at any > point during a replay. The latter isn't as easy as it sounds, since most > FDMs don't really like being repositioned or even having the speed > changed externally. Many (many) months back I had a build of flightgear where there was a bug-feature that actually allowed this to happen. I forget exactly how I triggered it and maybe it is/was still possibleI think it was some magic combo of reset/pause/unpause during a replay. It worked quite well and smooth on some aircraft, I remember shooting an approach over and over again by triggering it. Would be cool to see that work again, as an actual feature this time. :) > Another thing, since the topic was raised: since FG2.4.0 the multiplayer > system is already aware of replay sessions - and already freezes the > state. Other pilots are no longer annoyed by remote replay sessions. > It's still a good idea though to start the replay only while in a > parking position – since other MP players could still see your aircraft > squatting the runway or frozen in mid-flight. Could we have replays broadcast over mp as a hidden option or something, something that is disabled by default? It was actually kind of useful sometimes to be able to see other peoples replays. Having it hidden and/or disabled by default should prevent most/all unintentional bad behavior. And we have the ignore options on MP to get rid of any intentionally annoying people. > The most obvious change though is probably the new GUI dialog: looks > like a video player, provides play/pause/skip controls, also controls > replay speed. You can also use the 4 arrow keys to control replay (they > were useless during replay so far). > Finally, since replay can be paused now, it was necessary to move the > "stop replay" key binding to the "ESC" key (instead of pressing "pause" > twice) – which feels more intuitive to me anyway. > Hope some people find all this a bit useful - so have fun. I recommend > you take your favourite aircraft for a ride and then replay and evaluate > your landing using the new slow-motion support... ;-) And I'm sure > you'll let me know when things aren't working as expected... This sounds really awesome, really. I'm really looking forward to the future when all aircraft have configured themselves to have flawless replays, instead of being half crippled most of the time like they have been for so long. :) cheers..and thanks! --Jacob -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
Seems like most people are just banging their heads against the wall trying to make a new system the same as the old, which is counter productive and unfortunate. It is highly unlikely ANYONE needs every single aircraft from git that they were previously forced to take, which is the whole point of the change. If people are honest with themselves I think they would realize they only need such aircraft that they plan to use or do development on. Personally I am extremely happy that I will no longer need to pull down hundreds of aircraft I have no intention of ever touching just so I can work on and test development new development in flightgear. In the end this will make it much, much easier for new developers and testers to get up and running and get to work. cheers --Jacob -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
I understand there are a some cases where one might need all aircraft to perform some specific task, and when I said "unlikely ANYONE would" I could have spoken better. However for the vast majority of developers, contributors, and testers, I have to believe it is completely unnecessary or desired to get everything. For those power developers that DO actually need everything, I also have to believe they are more than capable of figuring out how to import some repos, run a script, etc. It is not wise to continue to let fgdata repository just grow and grow without end, it cannot be sustained in that manner indefinitely. More aircraft are created all the time, it is not going to get smaller or easier for people to work with. How many people have we already alienated, who may have otherwise been able to contribute, simply because they do not have access to the bandwidth necessary to deal with fgdata at no fault of their own? cheers -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after
On Wed, Oct 19, 2011 at 3:49 PM, Martin Spott wrote: > Jacob Burbach wrote: > >> Seems like most people are just banging their heads against the wall >> trying to make a new system the same as the old, which is counter >> productive and unfortunate. > > I wonder by which justification you pretend to speak for a group whose > common understanding you never bothered to share !? > > Martin. I speak for no person and no group, nor do I pretend to do so. I speak only about a general recurring theme in this discussion in which many seem to be struggling to find a simple, hands free way to get a monolithic fgdata back. Sure, some may have some use or actual need for it, but it really seems many are searching for a problem that doesn't really exist as such. cheers --Jacob -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
On Sun, Nov 6, 2011 at 9:10 AM, HB-GRAL wrote: > Just a technical question: I know it is not a big deal to convert new > textures to .dds format, but when I want to start to work on textures > should I convert back to another format and convert to dds again ? Or > should I start with origins and where are this origins going to ? DDS/DXT is lossy so in general you would want to use source textures of another (lossless) format and only convert to dds for final distribution. cheers -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
> In many cases the original files are the .png. And when new textures added as > only .dds then take Gimp, add the .dds-plugin, open the file and see: > this is the origin! ;-) If your using dxt compression, which is why most people use dds, then it is NOT equal to the original image. Amount of degradation will depend on the image, resolution, type of dxt used, etc..but will never be the same or better quality. cheers -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
One could argue that things like dds do not belong in the 'source' data distribution at all, but be generated automatically by some tool when building the 'release' data. For example content devs only work with, and check in/out source imagery, and then run the tool to generate the final dds imagery when needed, ie for testing or release. Many projects work this way, each in their own way, but of course require some set up and tools to make it work. If this would this be a good path for fgfs to try though, I cannot say. Maybe something to think about though. cheers --Jacob -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
On Sun, Nov 6, 2011 at 3:03 PM, Gary Neely wrote: > The main win for DDS, at least from a game design point of view, is > the ability to maintain a kind of compression while loaded into the > graphics memory. This is (as far as I know) unique to DDS/DXT. There is a texture compression extension that is used to allow storing textures compressed in video memory. I don't know the details of compression used (could be vendor specific), or how it compares to dxt compression which gives you 4x or 8x compression levels though. With dds the artist has control of which compression type to use as well as specifying custom mip maps, which makes it the winner in my book. I see the real benefit of dds as the ability to use a much higher resolution for the same (usually less) memory cost, have user defined mip map images, and faster loading in many cases. Even though it is lossy format, it still allows for a much higher overall quality level with better resource usage in most cases. > DDS is relatively fast because it is natively supported by video > cards. But if I remember right, for pure speed of loading it's hard to > beat good-ol' RGB. Loading dds from disk is usually quite quick due to not needing to decompress it into main memory, generate mip maps, etc. I can personally testify that osg/fgfs can load dds textures several magnitudes faster than the png counterpart...not sure about rgb. cheers --Jacob -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
On Sun, Nov 6, 2011 at 7:17 PM, Robert wrote: > I hope that all you guys involved in the dds transition use > "nvidia-texture-tools" because: > 1. It is Free/OpenSource and platform independent > 2. The compression quality is much higher than with the dds-plugin for GIMP However, and correct me if I'm wrong, the nvidia tools do not let you use pre-defined mip maps do they? I prefer the nvidia tools if for no other reason than they are command line and I can easily script and automate batch jobs. But if you do need pre defined mip maps I don't believe you have a choice except the gimp plugin..on linux anyway. cheers -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Southwest Colorado Scenery
I've tried on both 2.4 and git. On 2.4 it causes an abort (uncaught exception), and on git it loads but the terrain is very deformed, as if it exploded in many directions. cheers --Jacob -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
flightgear-devel@lists.sourceforge.net
On Thu, Jan 19, 2012 at 1:31 AM, Mathias Fröhlich wrote: > Yes, the usual user might ask 'what should I do?' > > What about: > Image "..." > uses compressed textures which cannot be supported on some systems. > Please decompress this texture for improved portability. How about something along the lines of this? Image "PATH TO IMAGE" uses compression which may not be supported on some systems/drivers. Please consider using uncompressed textures instead for increased portability. Please see "INSERT LINK TO MORE DETAILED INFORMATION ON THE ISSUE AND THE PROS / CONS OF USING THIS TYPE OF IMAGERY/COMPRESSION SO PEOPLE CAN MAKE INFORMED DECISION" for more information. Polite, informative, and provides link to information about what the deal is and what they can do about it (or not). cheers --Jacob -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re : Re : Looking at a nice project from outside
Though I myself have an independent scenery project, I whole heartedly support the global scenery project. Without it, and all your hard work on it over the years, flightgear scenery would be a mere shadow of what it is today. I hope then, after a break and some rest, that you will regain your passion and motivation for the project and find a way to continue on with it..even if in a reduced capacity. I say give no thought to people creating external scenery. As far as I have seen none of it was created out of spite towards the global scenery database, nor do I recall any of its authors saying there motivation for creating it was because they disagree with the global scenery project or have any ill will towards it. In fact the only reason I see that much of it exists is out of necessity..either due to past license issues with data...or now as a temporary measure while we wait for tools to stable up and a new global scenery generated with that data. Of course there are a few oddball projects about where people create 'exlusive' scenery objects or airports or whatever...which I don't care for personally...but those are the exception not the norm. I doubt anyone would disagree that the global scenery is by far the most important scenery project, without which fgfs scenery would be in a much worse state. However I don't believe the official global scenery project and independent scenery projects are mutually exclusive. There is a time and place for both in my opinion. best wishes..cheers -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery loading cleanup
On Sat, Mar 17, 2012 at 4:57 PM, Martin Spott wrote: > Anders Gidenstam wrote: > >> While the (old) new behaviour is as Martin expects it is not what most >> that has read Docs/README.scenery would expect (I'd think). However, I >> would not consider Docs/README.scenery a normative source (i.e. not how >> it should be but rather how it was) - but Martin's expectation (as far as >> I know about it) is also not the behaviour I'd like or want. > > Well, to put it a bit harsh, if you ask every user, you'll probably > have to implement two dozend exceptions from the rule. This doesn't > make neither the developer happy nor the users, because it's getting > too confusing - and the same users will start complaining again > > Let me explain it this way: > Nowadays we/you are confronted with a steadily growing number of > private Sceneries. There might be a scenario for France, one for Great > Britain, one for Germany and, because everybody needs to have their own > Scenery kingdom and these were the only ones left, one for BeNeLux and > one for Denmark. Because it's easier to maintain, the boundaries of > all these scenarios are aligned with full degrees. All these scenarios > are added to the scenery path. > Now think of an item which is situated somewhere in the German Bight in > a tile which doesn't have terrain, how often is every single windmill, > oil rig, buoy, light ship or whatever else going to be drawn in > FlightGear ? ;-) > > Therefore I'd say the only really consistent way of dealing with the > scenery path is to stop searching the path whenever a terrain _or_ an > object tile is found in a scenery path item. Seems logical to me that objects and terrain should be considered separately. The loader should not stop looking for an object bucket just because it finds a terrain bucket...and vice versa. The loader knows what bucket it is looking for, so should just need to look through each path until it finds the first existing bucket of each type (or none) and load the data for that bucket/type as appropriate. Once it has found a particular type of bucket it no longer looks for it anymore, but continues looking for the other types until it finds one, or not. Seems simple enough to me, avoids any problem with things loading twice, and gives a very logical and expected behavior for loading..no? cheers Jacob -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Switching from PUI to osgWidget
On Sun, Jul 22, 2012 at 6:42 PM, HB-GRAL wrote: > Am 22.07.12 22:40, schrieb Thomas Geymayer: >> Hi Stefan, >> >> Am 2012-07-21 22:46, schrieb stefan riemens: >>> It's obviously a long time wish to get rid of the PLIB dependency, and >>> one of the main subsystems using it is the GUI. There are a couple of >>> things lacking in possibilities with the current implementation: >>> - Proper internationalisation. PUI doesn't support UTF-8, limiting >>> i18n support tremendously. >>> - Things like submenus >>> - The code is pretty messy, by the looks of it mostly due to the >>> oldness of PUI and its API >> >> Have you seen my ongoing efforts towards a unified 2D drawing system >> called Canvas (http://wiki.flightgear.org/Canvas). It basically allows >> drawing 2D shapes (with OpenVG) and text (using osgText::Text). >> >> As it uses osgText for textrendering, supporting UTF-8 is very easy. I >> just tried it and with changing a single line of code now also using >> UTF-8 is supported. >> >> Currently only drawing inside an existing (PUI) dialog is possible, but >> the idea is to slowly implement the current functionally in Nasal and >> get rid of the hardcoded PUI widgets. Only some code for mouse/keyboard >> interaction with Nasal will be needed. >> >> In contrary to using some hardcoded GUI system (PUI, osgWidget, etc.) >> this approach would give much more flexibility and also the means of >> modifying and creating new widgets without the need to touch any core code. >> >> With the Canvas system every type of widget would be possible, so that >> also things like submenus can be realized. >> >> Another advantage of the Canvas approach is that it is heavily using the >> property tree and therefore is already fully accessible from Nasal code >> and also configurable with the existing xml formats. >> >> Switching to another scripting language or adding support for a new one, >> I think would be far too much work and not worth the efforts. >> >> Regards, >> Tom >> > > I don’t know what is it worth to think about a GUI inside fgfs at all > sometimes. When I look to what can be done i.e. with the FGx launcher, > properties and now HLA/RTI I’m thinking about trying to skip the > built-in GUI at all ;-) > > Cheers, Yves > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel Might be worth having a look at http://librocket.com, looks to be a very powerful and well done gui system. Uses html/css based files for creating, laying out, and styling the gui...has some support for interfacing script engines (ie nasal), localization, etc. This is the route I'd probably go personally if I were to do this...or any game/sim/3d project needing a gui... -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] dhc2 beaver mods
Hello everyone, I got bored today and made some new wheels for the beaver. They have more detailed tires and rims with livery, and they are animated to spin in ground roll. The uv mapping and livery modifications were done rather quickly, so I won't be offended if they get changed around. Overall though I think the wheels look pretty good... A couple other things I noticed. In the dhc2-sound.xml, mp-inhg should be replaced with mp-osi so engine sound will work in replays. The other thing was ground handling, the turn radius seemed very large for a tail dragger/bush plane. I had often had troubles getting it turned around to take off again. I saw that dst0 and dst1 for tail wheel steering are set to 0.5/-0.5, I changed to 1.0/-1.0 and feels much better to me, I can actually swing it around now. On the other hand, I have no real idea what a beaver handles like on the ground...so just thought I'd mention it. couple shots of them in flightgear http://farm4.static.flickr.com/3511/3799201057_30dbd47864_o.jpg http://farm4.static.flickr.com/3556/3800020854_46ae65b609_o.jpg and zip containing the modified wheels.ac, wheels.xml and liveries - for cvs version http://www.mediafire.com/?m30udyxgxce hope the dhc2 guy reads this list, and hope I don't step on anyones toes modifying things... cheers! -- Jacob (aka Tuxklok) -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] dhc2 beaver mods
I guess I kinda worded that oddly, no offense meant syd. :) cheers! -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] dhc2 beaver mods
I use replay to admire my bad landings ;) Hardly an important thing, but thought I'd point it out since it's a simple one to fix. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] dhc2 beaver mods
> Looks good , Ive commited your work, but changed the wheel rotation to use > my nasal tire-rpm and spin down script. > Thanks for the nice work . Thanks syd. Your wheel spin code looks great, the spin down on take off is nice touch. Will the wheel spin work over multiplayer, or could it be made to do so without too much trouble? Would be neat. > I'll leave the mp-osi alone until I know what direction we're going with > that.Might be better to change the replay code if we're going to remove > that property. I'll just modify my local copy to use mp-osi until it is sorted, no worries. I think the whole replay thing needs an overhaul anyway. There seems to be a missing file in cvs right now. I get `Failed to load file: "Aircraft/dhc2/Models/panel1.xml"', and my panel is completely empty. :D cheers! -- Jacob (aka Tuxklok) -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] dhc2 beaver mods
On Sat, Aug 8, 2009 at 12:42 PM, syd adams wrote: > OK panel fixed Thanks syd, everything is working great now. cheers! -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Till Busch's terrain shaders
> Hi on my wish list for eye candy would be: > > 1. Shadows (aircraft shadows cast on to itself and onto the ground.) > > 2. Wet runways that reflect some sort of foggy, fuzzy something or other. > Like glass effects except more wet runway-ish. > > 3. Proper landing lights that illuminate the scene. > > Curt. > -- > Curtis Olson: http://baron.flightgear.org/~curt/ All things that advanced materials and shaders will help to make possible. :) This is good stuff...even though it means I'll need a new gpu soon cheers! -- Jacob (aka Tuxklok) -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest CVS still showing major MP problems...
Same thing here, ongoing for at least 2 weeks. People often missing in chat and mp list, though I can see them visually. Sometimes it seems to only let me "see" two others in the chat/mp_list at a time, other times I can see more, and rarely can see everyone. I have zero nasal errors, or errors of any other kind. cheers -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Newsletter August 2009
While it would be neat if flightgear could generate the default scenery off of high quality data, there is still a fair bit of manual work involved to get good results. OSM and Corine, while both very accurate, don't necessarily agree with one another. I've spent a considerable amount of time tweaking the roads and rails to clean them up, and move them to agree with Corine, especially around the lakes and rivers. The other thing I'm spending a fair amount of time on is the identifying tunnels for roads and rails, so they do not cut through mountains and such. A fair number of people have commented on my scenery about "that strange peak near LOWI" being fixed. That was was caused by railroad cutting through it in the default scenery. In real life that is a tunnel, and I cut out those parts of the rails that are tunnel in that area. Stuff like that would be hard or impossible to automate, good scenery simply needs real hands working on it. Besides, there are advantages to not having the scenery part of the official scenery. Sometimes it is necessary to step outside of "official" channels in order to achieve your goals, or push things to a new level. For me to achieve my long term goals for the scenery, I simply cannot follow some "official" methods, practices, and recommendations. In other words, even if I used gpl compatible data I would still be maintaining my scenery separate from flightgears official scenery. ;) cheers! -- Jacob (aka Tuxklok) -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Newsletter August 2009
> Next time you do that you'd probably consider acknowledging the > respective attributes in the OSM data: They're explicitly marking these > sections of the railroad as running through a tunnel ;-) Interesting, seems I may have totally overlooked that one, I'll look into it. I can prob have those sections automatically removed at the beginning of my pipeline then. That could save a lot of time, and put me one step closer to having the base terrain done. Then I can move onto the more interesting things. Thanks Martin! cheers! -- Jacob (aka Tuxklok) -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Newsletter August 2009
> I'm pretty much convinced that your goal and ours are not that far > apart from each other. In other words: "pushing things to a new level" > doesn't make your project a unique one. Indeed, I think everyone working on scenery shares some common goals. There is currently nothing unique about my work, in fact everything I've done so far has been done before, I'm not breaking any new ground here. ;) cheers -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer ATC "aircraft,
I spy a java icon... ;) -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGCOM troubleshooting help...
> OpenAl function alcCaptureOpenDevice failed with code 0 > FATAL ERROR: cannot initialize iaxclient!" It's an OpenAL problem. Try installing the latest OpenAL from http://connect.creativelabs.com/openal/Downloads/Forms/AllItems.aspx ? -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGCOM troubleshooting help...
Does flightgear run the the OpenAL installer during setup, or does it just come with it's own dll? If there is an openal dll in the same directory as fgcom it will use that, regardless of anyone you install system wide I believe. If there is an openal dll there with the exe, try moving it or renaming it and see if it works. All I can think of off the top of my head. cheers -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest CVS still showing major MP problems...
Missing persons are listed in /ai/models/multiplayer[*], and /ai/models/multiplayer[*]/valid is true. Yet they do not show up in mp list, nor can I see there chat. Something has obviously changed within the last few weeks, was fine before that. Another one of those flightgear mysteries I guess... cheers! -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Normal maps
Normal maps require materials with multiple texture units and shaders, as well as some code to make the vertex attributes available to the shader. The new material system being developed supports texture units and shaders, but is still very very young, and only for terrain currently. So no, it's not possible yet, but it should be at some point in the future. cheers --Jacob -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Autopilot changes
In recent cvs I get errors about having Ki or Kd in my pid controllers config. This is unfortunate, as tuning of those values stabilized my autopilot considerably. I wonder if someone can explain what changes are going on in that area of code. Are Ki and Kd forever gone, and what path should I take for tuning autopilot to work in new/modified system? cheers! -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot changes
Will get error such as > malformed autopilot definition - unrecognized config node:Ki in section > Heading Bug Hold > Failed to load autopilot configuration: /path/to/autopilot.xml:XMLAuto: > unrecognized config node:Ki Removing Ki, it will then complain about Kd. Can remove Ki and Kd and it will work, but obviously the autopilot won't work so well anymore. Looking in xmlauto.cxx I can see Ki is available in a pi-simple-controller, but Kd seems to be gone completely. So for now I guess I'm stuck, all I can do is remove all references to Ki and Kd, and deal with an unstable/inaccurate autopilot. Is the autopilot stuff undergoing some major changes, did I catch it in a bad state? Where did Ki and Kd go? cheers -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot changes
I must be losing my mind then, I had both Ki and Kd in pid-controller without errors previously, and changing the values certainly had an effect. On another note, theres a bug in FGAutoBrake::postInit. It's using _weightOnWheelsNode without checking if it is actually a valid pointer. With atc aircraft it's null, and causes a segfault. cheers -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fg-home on windows and mac
In Linux the users flightgear directory is at /home//.fgfs. As I don't have a windows pc and haven't yet tried flightgear on my mac, I wonder if someone can enlighten me to the path for the users directory on those systems. Thanks! -- Jacob -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Fwd: fg-home on windows and mac
In Linux the users flightgear directory is at /home//.fgfs. As I don't have a windows pc and haven't yet tried flightgear on my mac, I wonder if someone can enlighten me to the path for the users directory on those systems. Thanks! -- Jacob -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: fg-home on windows and mac
Thanks guys. The reason for asking is that you can put nasal scripts in fg-home/Nasal, and they will be loaded only after the scripts in fg-root/Nasal have been loaded. It guarantees you will have access to all the flightgear nasal apis from your script at load time. Ok, so XP and prior should be "C:\Documents And Settings\\Application Data\flightgear.org" and Vista and up would be "C:\Users\\appdata\roaming\flightgear.org". Is that right? I'm thinking Mac might be the same as on Linux, but will have to wait for someone to confirm that. thanks --Jacob -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
> The way the MP protocol is done now you really really do not want to do > that by creating a new MP enabled string property and put the flight-plan > in it. Not only is the string encoding horribly inefficient (a 32bit word > per character) but it would also be sent in each and every packet. Wow, that's really bad, why are strings being encoded with 32 bits per character exactly? --Jacob -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pauses in flightgear
Does turning off the shaders make any difference? -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] BUG - Evening, Rain, Propeller
So how does one to fix the issue on the aircraft then? In the tu154b I cannot see rain or snow outside the cockpit at all do to (I think) the transparency on the windshield. The rain/snow/etc inside the cockpit should be easily fixable using the depth buffer, but I'm not familiar with the flightgear/simgear/osg code base so I cannot be any help actually implementing in flightgear. Theres also a bug with the rain/snow when moving the camera around, in that it a appears to `speed up'...not sure a better way to put it. cheers! -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ignoring MP pilots
Trying to fit everyone into a few "pre-defined" groups is not a very good idea in my opinion. Peoples wants, needs, and uses are to varied to be known ahead of time. It also doesn't address the need for an ignore chat / ignore model feature, as having a group doesn't not mean people will behave appropriate for that group..purposefully or ignorantly. With that in mind, I would first implement the ignore chat / ignore model functionality. On the pilots list next to each client should be two buttons, one for ignoring chat, and one for ignoring the model as well. A group system would require more thought and effort I think...and should be done properly if at all. Ideally I think one should be at least be able to create, join, and leave a group at runtime. Groups could be removed automatically when there are no more users in it. Maybe mp should evolve to be more like an IRC server/client...with similar featuresbut obviously requires a lot of work and changes. just my 2 pennies cheers! --Jacob -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Clouds
> My screenshot didn't show the proposed menu structure, so here it is: > > View > - Display Options > - Rendering Options > - Cockpit View Options > - Adjust View Distance > - Adjust HUD Properties > - Instant Replay > - Adjust LOD Ranges* While we're at it, could "Adjust View Distance" be changed to "Adjust View Position", since that's what it actually does? cheers --Jacob -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Sound system improvements...levels, sources, balancing, and devices...
Since the sound system is undergoing major development, I guess now would be a good time to mention some things that I think need addressing... First, we really need better control of sound levels and balancing between different sound sources. It is often impossible to hear ATIS over the aircraft sounds for example. Having one master volume control and volume properties on the radios is not enough. I think breaking it into different groups of sounds...aircraft, radios, etc...and having master controls for each would be a good solution. Secondly, I think it would be beneficial to have the ability to specify a sound device for a certain group. So you could, for example, send aircraft sounds to your speakers, and radio sounds to a headset. any thoughts? cheers! --Jacob -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound system improvements...levels, sources, balancing, and devices...
>> First, we really need better control of sound levels and balancing >> between different sound sources. It is often impossible to hear ATIS >> over the aircraft sounds for example. Having one master volume control >> and volume properties on the radios is not enough. I think breaking it >> into different groups of sounds...aircraft, radios, etc...and having >> master controls for each would be a good solution. > > Not a bad idea. Good thing that is what I've implemented in the past > months and which is in CVS now. So you've already implemented separate master sound controls for radios and aircraft and/or other groups already...such as would be configurable from the sound config dialog? My copy of CVS doesn't currently include the new sound system...so if so that's awesome..and just ignore me then. ;) >> Secondly, I think it would be beneficial to have the ability to > >specify a sound device for a certain group. So you could, for example, >> send aircraft sounds to your speakers, and radio sounds to a headset. > > Could be done with the current code but is low proirity for me. Understandable > The only useful split I know of, is radio sounds separate to > 'cockpit/exterior' sounds. Yes, currently only aircraft and radio sounds are logical groups, but it's also possible others could exist in the future. So it could be beneficial to have it setup so to be extended easily with more independently adjustable groups down the road I guess. > That's actually why I was working on fgcom device support on Mac - my > preferred setup is FG sounds from my line out > (which goes to speakers, including a sub, for nice rumble) and all fgcom > through my USB headset. Unfortunately this > doesn't work due to aforementioned OpenAL laziness on the part of Apple ... > so I'm stuck with fgcom coming out of the main > speakers, which is much header to discern above cockpit / engine noise > just like RL I guess. This is exactly my setup in linux already, flightgear outputs to my surround sound system, and fgcom outputs to my usb headset. I also have it configured so I can use fgcom with comm1 and comm2 simultaneously, comm1 to left channel, comm2 to right channel...selectable at run time which I transmit on. So if I could get flightgear to send radio sounds to my headset as well I'd be a very happy guy.. :) > Anyway, since fgcom is a separate process, this is not much to do with FG - > except that ideally ATIS and other services would *also* > be delivered via > FGCom, which would clean up a whole bunch of things. It would be neat if fgcom (or future replacement) implemented atis somehow. Yet not everyone uses fgcom so flightgear needs it's own atis still obviously, which might lead to strange results when I tune my radio to atis and flightgear AND fgcom start giving me weather info at the same time. :D > To go a bit into the technical details: > It is already possible to create a second SoundMgr class and initialize > it with a different device name. Now you have two different sound output > devices to which you can assign SampleGroups to. This sounds really good, so the code to make independant groups with different devices is therejust needs an interface configurable through gui to manage it. It would be awesome to have the sound config dialog show a master volume slider for each group, as well as a drop down to select a device for that group. If changing the devices at run time is problematic, command line options to set it at start up would be acceptable as well I guess. cheers! --Jacob -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound system improvements...levels, sources, balancing, and devices...
On Wed, Dec 2, 2009 at 7:52 AM, Erik Hofman wrote: > You really should use CVS.. > > Erik I do. :) Though I do so selectively as to keep it usable for me and to avoid conflicts with my personal modifications. So no, I'm not 100% inline with current cvs, including I haven't yet merged in the new sound system. The sound system, and some other changes, made flightgear mostly unusable previously, though looks like it's stabilizing a bit now so I should make a new migration soon. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound system improvements...levels, sources, balancing, and devices...
On Wed, Dec 2, 2009 at 8:29 AM, Csaba Halász wrote: > On Wed, Dec 2, 2009 at 2:07 PM, Jacob Burbach wrote: >> On Wed, Dec 2, 2009 at 7:52 AM, Erik Hofman wrote: >>> You really should use CVS.. >>> >> >> I do. :) Though I do so selectively as to keep it usable for me and to >> avoid conflicts with my personal modifications. So no, I'm not 100% >> inline with current cvs, including I haven't yet merged in the new >> sound system. > > Nah, you should be using git :) > Then you could easily track the current development version while also > having your own branch. > > -- > Csaba/Jester Yes, but that's only recently become an option with flightgear and I haven't felt bothered enough to move yet. ;) -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound system improvements...levels, sources, balancing, and devices...
Ok, so I went ahead and did a build of the latest and greatest...looks (and sounds) really good. I love when when features are implemented faster than I can ask for them! ;) A couple observations: 1. Cannot adjust volume of atis(comm radios) from sound config dialog. Not a "major" issue I guess since I can mostly tune it with increasing master and lowering effects/avionics. Can also adjust with the actual comm volume control of course, but not all aircraft have working radio controls. Having to monkey with the levels of all other volume controls to get comm volumes proper, and possibly having to make fine adjustments to comm volume from property manager does raise some usability issues though. Might be worth adding a comm radio control to the sound config dialog as well. 2. Adjusting the volume of the comm radios causes the atis to jump to a different position in her dialog...doh! Other than that everything seemed to be working pretty well(sound wise anyway)thanks for all your hard work! I know you said different devices per group are not a priority for you, but if you could work it onto your todo list for the future that would be great. I'm sure I'm not the only one who would find this extremely useful. cheers! --Jacob -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound system improvements...levels, sources, balancing, and devices...
On Fri, Dec 4, 2009 at 3:13 AM, Erik Hofman wrote: > Jacob Burbach wrote: >> A couple observations: >> >> 1. Cannot adjust volume of atis(comm radios) from sound config dialog. > > I believe it is meant to be adjusted on the aircrafts audio panel. At > least they are not exposed to properties which makes it difficult to > adjust using the gui. If people think it would be a good idea it's easy > to tie them to properties though. Having thought about this some more, I think the comm radios should probably belong to the avionics group rather than a new, separate group. This way you could easily adjust all radio (nav and comm) volumes relative to other groups, and then use the individual radio volumes from the aircrafts audio panel(if it has one) for fine tuning each relative to each other. >> 2. Adjusting the volume of the comm radios causes the atis to jump to >> a different position in her dialog...doh! > > I'm not sure I completely understand this, the atis (chatter) slider of > the sound configuration panel moves with the adjustment of the aircraft > audio panel volume? If I adjust the volume for the radio tuned to ATIS, it will skip to a completely different part of the speech with each adjustment. It's seems the ATIS audio stream is getting restarted in a different position (or maybe regenerated?) every time the comm radios volume is adjusted. Tune a radio to ATIS, and then start adjusting that radios volume and it should become very clear what I mean. On another note, I have noticed some cockpit sounds change volume randomly, as if the volume or distance changed for some unknown reason. This is without having changed the view position and orientation in any way. For example, in the tu154b toggling the switch for the autopilot system will give you a short series of beeps. I can stay in same view, toggling the switch off and on, and the volume will often change randomly, sometimes normal, sometimes very quiet. cheers! --Jacob -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound system improvements...levels, sources, balancing, and devices...
I have been experimenting with generating custom, realistic, and more useful ATIS message on FGCOM using Festival with great success. The only problem is that when tuning to the ATIS frequency you get the FlightGear default ATIS as well, which is not very useful. So one last request to do with ATIS, may we have a check box in the sound config dialog to toggle the FlightGear ATIS on and off? Or do we already have a way to do so that I have overlooked? cheers! --Jacob -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound system improvements...levels, sources, balancing, and devices...
On Sun, Dec 6, 2009 at 4:20 AM, Erik Hofman wrote: > Jacob Burbach wrote: > >> So one last request to do with ATIS, may we have a check box in the >> sound config dialog to toggle the FlightGear ATIS on and off? Or do we >> already have a way to do so that I have overlooked? > > I could not find a reference in the code or in one of the xml files, so > I guess it's not possible at this time. I'll add it to the todo list. > > Erik > I traced the code back to FGATC::Render and found reference to '/sim/sound/voice'. Setting this to false does indeed seem to get rid of the ATIS, but has some problems. Changing this value while tuned to ATIS can lead to strange results...ATIS not turning off when tuned away or not turning on again when tuned in. If your careful to set it false before tuning in, it does disable the ATIS speech though, but you have to be careful to only set it true again when tuned away. I also found that '/sim/atc/enabled' seems to have the same effect, with the same quirks/bugs. cheers! --Jacob -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] bug with taxiway signs
I don't know if this is known, but I don't remember seeing reference of it. With 1.9.1, using release scenery or terrasync, signs are drawn correctly. With cvs, also with terrasync or release scenery, signs are missing letters, making them not so useful. To see the problem start up at KLVK(for example, but effects all airports), in 1.9.1 and taxi around, then do the same in cvs, the problem should be clear. For example, excuse the crude ascii drawings if you will ;) Taxiing up Bravo towards Alpha and Juliet (KLVK) with 1.9.1 you will see these signs...correct. | <-- A[B] | [ <-- J[B] | But in cvs letters for Alpha and Bravo will be missing, and you will see these signsnot so correct. | <--[B] | | <--[B] | This effects all signs, at all airports I tried, release or terrasync scenery cheers! --Jacob -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adjusting the Adjust View Distance
Switch to mouse look view, push the middle mouse button and drag to adjust view left, right, up, and down. Press control + middle mouse button and drag to adjust view forwards and backwards. I find that's much easier for fine adjustments. Once your done adjusting you can find the current view settings in "/sim/current-view", which you can then transplant to the aircrafts set file to make permanent. The large range in the adjust view dialog is useful for big changes, like getting many tower view above ground for example. :) cheers! --Jacob (aka Tuxklok aka N1292P) -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgfs compile error, today's cvs
A simple make clean && make was enough to get the ball rolling for me. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nan-a-palooza
I never have the ai traffic enabled, but still get nans sometimes. The ai traffic may be triggering a nan, but I'm not sure it's actually the root cause. Debugging nans can be a real pita, with every operation against a nan producing a nan they spread like wildfire. By the time it causes a problem it's usually a long way from the origin. Anyway, I really hope a release won't be rushed with problems like these still present. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Version number for the upcoming release
Traditionally it is MAJOR.MINOR.PATCHLEVEL, definately more than a patchlevel thing, and way more than minor, so either 1.10.x or 2.x.x if your following that standard. 1.10 feels weird, but not sure 2.x is warranted just yet. Could ditch all that and use dates ala ubuntu, making it what...like 12.9? :D But, are we really going to try and rush the release out by years end? Nan errors still abound, sound system has lots of rough edges still, the new material system is not finished, route manager not finished, etc, etc. Even if everything could be cleaned up by then, there would be no time left for any real testing/bug fixing. Seems like a bad idea to me. Or would it be a release candidate type thing? Has development even been frozen and branched yet? cheers! --Jacob -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Version number for the upcoming release
> Bug-fixing, testing, etc is of course a separate issue - namely that fixing > bugs is a lot less fun than writing features. As a developer I certainly won't disagree with that, but they are an absolute necessity for any software, it just comes with the territory. As a user I would also say a stable release is a lot more fun than a half finished, buggy one. ;) cheers --Jacob -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Version number for the upcoming release
I don't think anything wrong with the MAJOR.MINOR.PATCHLEVEL format, I think it's fairly obvious, and is widely used. I'm not a huge fan of rolling over into double digits though, unless you started with double digits to begin with. For example 1.09 to 1.10 is logical to me, but 1.9.1 to 1.10 is not, I would expect 1.9.1 to be the newer in this case. Perhaps it is time to go to 2.0 then, in hindsight osg should have probably been 2.0 being such a major change in direction. Being 2.0 can also give some leeway to excuse the bugsI mean hey, we're in the infancy of a new major number release...of course there are flaws. :D :D cheers! --Jacob -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nan-a-palooza
Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 0xb627aa20 (LWP 30813)]
0x0865ece2 in findcell (hr=0xeb43550, key=
{num = nan(0x567891077bfa8), ref = {ptr = {obj = 0x1077bfa8,
str = 0x1077bfa8, vec = 0x1077bfa8, hash = 0x1077bfa8, code =
0x1077bfa8, func = 0x1077bfa8, ccode = 0x1077bfa8, ghost =
0x1077bfa8}, reftag = 2146789257}}, hash=4111002719) at
../../../simgear/nasal/hash.c:67
67 if(IS_NUM(a)) return a.num == b.num;
Current language: auto; currently c
(gdb) bt
#0 0x0865ece2 in findcell (hr=0xeb43550, key=
{num = nan(0x567891077bfa8), ref = {ptr = {obj = 0x1077bfa8,
str = 0x1077bfa8, vec = 0x1077bfa8, hash = 0x1077bfa8, code =
0x1077bfa8, func = 0x1077bfa8, ccode = 0x1077bfa8, ghost =
0x1077bfa8}, reftag = 2146789257}}, hash=4111002719) at
../../../simgear/nasal/hash.c:67
#1 0x0865f35d in naHash_get (hash=, key=
{num = nan(0x567891077bfa8), ref = {ptr = {obj = 0x1077bfa8,
str = 0x1077bfa8, vec = 0x1077bfa8, hash = 0x1077bfa8, code =
0x1077bfa8, func = 0x1077bfa8, ccode = 0x1077bfa8, ghost =
0x1077bfa8}, reftag = 2146789257}}, out=0xbfdea690) at
../../../simgear/nasal/hash.c:130
#2 0x0865be74 in naInternSymbol (sym=
{num = nan(0x567891077bfa8), ref = {ptr = {obj = 0x1077bfa8,
str = 0x1077bfa8, vec = 0x1077bfa8, hash = 0x1077bfa8, code =
0x1077bfa8, func = 0x1077bfa8, ccode = 0x1077bfa8, ghost =
0x1077bfa8}, reftag = 2146789257}}) at
../../../simgear/nasal/codegen.c:74
#3 0x086586c9 in naNewContext () at ../../../simgear/nasal/code.c:190
#4 0x084c3bbe in FGNasalSys::init (this=0xeb30d50) at
../../../src/Scripting/NasalSys.cxx:650
#5 0x0808e3f0 in fgInitSubsystems () at ../../../src/Main/fg_init.cxx:1709
#6 0x0806d0f8 in fgIdleFunction () at ../../../src/Main/main.cxx:774
#7 0x080bbec2 in fgOSMainLoop () at ../../../src/Main/fg_os_osgviewer.cxx:172
#8 0x0806d8d5 in fgMainInit (argc=10, argv=0xbfdeab04) at
../../../src/Main/main.cxx:920
#9 0x0806baef in main (argc=10, argv=0xbfdeab04) at
../../../src/Main/bootstrap.cxx:229
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Version number for the upcoming release
What if we start naming releases in addition to the normal version scheme. FlightGear 2.x.x , name could be some continued variation on a theme or something. I think that would be a nice middle ground, we keep a meaningful versioning scheme, and also get a catchy name for everyone. I've worked on projects that have done this and it works well I think, the name usually changed for every meaningful release1.1, 1.2, .1.3...etc. cheers --Jacob -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nan-a-palooza
Not sure what you meant about gdb generating code to cause it, I get the same error when run outside of gdb. Assembly of the function below, if you need something else let me know. 0x0865ec50 :push %ebp 0x0865ec51 :mov%esp,%ebp 0x0865ec53 :push %edi 0x0865ec54 :push %esi 0x0865ec55 :push %ebx 0x0865ec56 :xor%ebx,%ebx 0x0865ec58 :sub$0x5c,%esp 0x0865ec5b : mov0x8(%ebp),%edi 0x0865ec5e : mov%edx,-0x38(%ebp) 0x0865ec61 : mov0x4(%eax),%edx 0x0865ec64 : mov%eax,-0x54(%ebp) 0x0865ec67 : mov$0x1,%eax 0x0865ec6c : mov%ecx,-0x34(%ebp) 0x0865ec6f : movl $0x0,-0x4c(%ebp) 0x0865ec76 : lea0x1(%edx),%ecx 0x0865ec79 : shl%cl,%eax 0x0865ec7b : sub$0x1,%eax 0x0865ec7e : mov%eax,-0x28(%ebp) 0x0865ec81 : mov-0x28(%ebp),%ecx 0x0865ec84 : lea0x1(%edi,%edi,1),%eax 0x0865ec88 : and%ecx,%eax 0x0865ec8a : test %edx,%edx 0x0865ec8c : mov%eax,-0x24(%ebp) 0x0865ec8f : je 0x865eca6 0x0865ec91 : mov$0x20,%ecx 0x0865ec96 : mov%edi,%ebx 0x0865ec98 : sub%edx,%ecx 0x0865ec9a : shr%cl,%ebx 0x0865ec9c : lea0x0(,%ebx,4),%esi 0x0865eca3 : mov%esi,-0x4c(%ebp) 0x0865eca6 : mov-0x54(%ebp),%eax 0x0865eca9 : mov%edx,%ecx 0x0865ecab : add$0xc,%eax 0x0865ecae : and$0x7,%eax 0x0865ecb1 : lea0x7(%eax),%edi 0x0865ecb4 : and$0x8,%edi 0x0865ecb7 : sub%eax,%edi 0x0865ecb9 : mov$0x10,%eax 0x0865ecbe : shl%cl,%eax 0x0865ecc0 : lea0xc(%edi,%eax,1),%eax 0x0865ecc4 : mov%eax,-0x2c(%ebp) 0x0865ecc7 : mov-0x54(%ebp),%eax 0x0865ecca : mov-0x2c(%ebp),%esi 0x0865eccd : add-0x4c(%ebp),%eax 0x0865ecd0 : mov%edi,-0x30(%ebp) 0x0865ecd3 : mov(%eax,%esi,1),%eax 0x0865ecd6 : cmp$0x,%eax 0x0865ecd9 : je 0x865edb8 0x0865ecdf : fldl -0x38(%ebp) 0x0865ece2 : fstpl -0x48(%ebp) 0x0865ece5 : jmp0x865ed21 0x0865ece7 : nop 0x0865ece8 : fldl -0x20(%ebp) 0x0865eceb : fldl -0x48(%ebp) 0x0865ecee : fucompp 0x0865ecf0 : fnstsw %ax 0x0865ecf2 : sahf 0x0865ecf3 : sete %al 0x0865ecf6 : setnp %dl 0x0865ecf9 : and%edx,%eax 0x0865ecfb : movzbl %al,%eax 0x0865ecfe : test %eax,%eax 0x0865ed00 : jne0x865edb8 0x0865ed06 : mov-0x2c(%ebp),%edx 0x0865ed09 : add-0x24(%ebp),%ebx 0x0865ed0c : mov-0x54(%ebp),%ecx 0x0865ed0f : and-0x28(%ebp),%ebx 0x0865ed12 : lea(%edx,%ebx,4),%eax 0x0865ed15 : mov(%ecx,%eax,1),%eax 0x0865ed18 : cmp$0x,%eax 0x0865ed1b : je 0x865edb8 0x0865ed21 : cmp$0xfffe,%eax 0x0865ed24 : je 0x865ed06 0x0865ed26 : mov-0x30(%ebp),%ecx 0x0865ed29 : shl$0x4,%eax 0x0865ed2c : add-0x54(%ebp),%eax 0x0865ed2f : cmpl $0x7ff56789,-0x34(%ebp) 0x0865ed36 : mov0xc(%ecx,%eax,1),%edx 0x0865ed3a : mov0x10(%ecx,%eax,1),%ecx 0x0865ed3e : mov%edx,-0x20(%ebp) 0x0865ed41 : mov%ecx,-0x1c(%ebp) 0x0865ed44 : jne0x865ece8 0x0865ed46 : mov-0x20(%ebp),%eax 0x0865ed49 : cmp%eax,-0x38(%ebp) 0x0865ed4c : je 0x865edb8 0x0865ed4e : mov-0x38(%ebp),%edx 0x0865ed51 : mov-0x34(%ebp),%ecx 0x0865ed54 : mov%edx,(%esp) 0x0865ed57 : mov%ecx,0x4(%esp) 0x0865ed5b : call 0x8665d60 0x0865ed60 : mov-0x20(%ebp),%esi 0x0865ed63 : mov-0x1c(%ebp),%edi 0x0865ed66 : mov%esi,(%esp) 0x0865ed69 : mov%edi,0x4(%esp) 0x0865ed6d : mov%eax,-0x50(%ebp) 0x0865ed70 : call 0x8665d60 0x0865ed75 : cmp%eax,-0x50(%ebp) 0x0865ed78 : jne0x865ed06 0x0865ed7a : mov%esi,(%esp) 0x0865ed7d : mov%edi,0x4(%esp) 0x0865ed81 : call 0x8665da0 0x0865ed86 : mov-0x34(%ebp),%edx 0x0865ed89 : mov%edx,0x4(%esp) 0x0865ed8d : mov%eax,-0x14(%ebp) 0x0865ed90 : mov-0x38(%ebp),%eax 0x0865ed93 : mov%eax,(%esp) 0x0865ed96 : call 0x8665da0 0x0865ed9b : mov-0x50(%ebp),%edx 0x0865ed9e : mov-0x14(%ebp),%edi 0x0865eda1 : cmp%edx,%edx 0x0865eda3 : mov%edx,%ecx 0x0865eda5 : mov%eax,%esi 0x0865eda7 : repz cmpsb %es:(%edi),%ds:(%esi) 0x0865eda9 : sete %al 0x0865edac : movzbl %al,%eax 0x0865edaf : jmp0x865ecfe 0x0865edb4 : lea0x0(%esi,%eiz,1),%esi 0x0865edb8 : add$0x5c,%esp 0x0865edbb : mov%ebx,%eax 0x0865edbd : pop%ebx 0x0865edbe : pop%esi 0x0865edbf : pop%edi 0x0865edc0 : pop%ebp 0x0865edc1 : ret -- Retur
Re: [Flightgear-devel] nan-a-palooza
I applied your hash patch, but no deuce.
Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 0xb62cba20 (LWP 25297)]
0x0865f79c in findcell (hr=0x107b5490, key=
{num = nan(0x56789123dabd8), ref = {ptr = {obj = 0x123dabd8,
str = 0x123dabd8, vec = 0x123dabd8, hash = 0x123dabd8, code =
0x123dabd8, func = 0x123dabd8, ccode = 0x123dabd8, ghost =
0x123dabd8}, reftag = 2146789257}}, hash=4111002719) at
../../../simgear/nasal/hash.c:67
67 if(IS_NUM(*a)) return a->num == b->num;
Current language: auto; currently c
(gdb) bt
#0 0x0865f79c in findcell (hr=0x107b5490, key=
{num = nan(0x56789123dabd8), ref = {ptr = {obj = 0x123dabd8,
str = 0x123dabd8, vec = 0x123dabd8, hash = 0x123dabd8, code =
0x123dabd8, func = 0x123dabd8, ccode = 0x123dabd8, ghost =
0x123dabd8}, reftag = 2146789257}}, hash=4111002719) at
../../../simgear/nasal/hash.c:67
#1 0x0865fe0d in naHash_get (hash=, key=
{num = nan(0x56789123dabd8), ref = {ptr = {obj = 0x123dabd8,
str = 0x123dabd8, vec = 0x123dabd8, hash = 0x123dabd8, code =
0x123dabd8, func = 0x123dabd8, ccode = 0x123dabd8, ghost =
0x123dabd8}, reftag = 2146789257}}, out=0xbf83b0e0) at
../../../simgear/nasal/hash.c:130
#2 0x0865c934 in naInternSymbol (sym=
{num = nan(0x56789123dabd8), ref = {ptr = {obj = 0x123dabd8,
str = 0x123dabd8, vec = 0x123dabd8, hash = 0x123dabd8, code =
0x123dabd8, func = 0x123dabd8, ccode = 0x123dabd8, ghost =
0x123dabd8}, reftag = 2146789257}}) at
../../../simgear/nasal/codegen.c:74
#3 0x08659189 in naNewContext () at ../../../simgear/nasal/code.c:190
#4 0x084c469e in FGNasalSys::init (this=0x1079e578) at
../../../src/Scripting/NasalSys.cxx:650
#5 0x0808e3f0 in fgInitSubsystems () at ../../../src/Main/fg_init.cxx:1709
#6 0x0806d0f8 in fgIdleFunction () at ../../../src/Main/main.cxx:774
#7 0x080bbf82 in fgOSMainLoop () at ../../../src/Main/fg_os_osgviewer.cxx:172
#8 0x0806d8d5 in fgMainInit (argc=10, argv=0xbf83b554) at
../../../src/Main/main.cxx:920
#9 0x0806baef in main (argc=10, argv=0xbf83b554) at
../../../src/Main/bootstrap.cxx:229
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nan-a-palooza
Dump of assembler code for function findcell: 0x0865f710 :push %ebp 0x0865f711 :mov%esp,%ebp 0x0865f713 :push %edi 0x0865f714 :xor%edi,%edi 0x0865f716 :push %esi 0x0865f717 :push %ebx 0x0865f718 :xor%ebx,%ebx 0x0865f71a : sub$0x4c,%esp 0x0865f71d : mov0x4(%eax),%esi 0x0865f720 : mov%eax,-0x38(%ebp) 0x0865f723 : mov$0x1,%eax 0x0865f728 : mov%ecx,-0x3c(%ebp) 0x0865f72b : mov%edx,-0x40(%ebp) 0x0865f72e : mov0x8(%ebp),%edx 0x0865f731 : lea0x1(%esi),%ecx 0x0865f734 : shl%cl,%eax 0x0865f736 : sub$0x1,%eax 0x0865f739 : mov%eax,-0x30(%ebp) 0x0865f73c : mov-0x30(%ebp),%ecx 0x0865f73f : lea0x1(%edx,%edx,1),%eax 0x0865f743 : and%ecx,%eax 0x0865f745 : test %esi,%esi 0x0865f747 : mov%eax,-0x2c(%ebp) 0x0865f74a : je 0x865f75e 0x0865f74c : mov$0x20,%ecx 0x0865f751 : mov%edx,%ebx 0x0865f753 : sub%esi,%ecx 0x0865f755 : shr%cl,%ebx 0x0865f757 : lea0x0(,%ebx,4),%edi 0x0865f75e : mov-0x38(%ebp),%eax 0x0865f761 : mov%esi,%ecx 0x0865f763 : add$0xc,%eax 0x0865f766 : and$0x7,%eax 0x0865f769 : lea0x7(%eax),%edx 0x0865f76c : and$0x8,%edx 0x0865f76f : sub%eax,%edx 0x0865f771 : mov$0x10,%eax 0x0865f776 : shl%cl,%eax 0x0865f778 : lea0xc(%edx,%eax,1),%eax 0x0865f77c : mov%eax,-0x34(%ebp) 0x0865f77f : mov-0x38(%ebp),%eax 0x0865f782 : mov-0x34(%ebp),%ecx 0x0865f785 : add%edi,%eax 0x0865f787 : mov(%eax,%ecx,1),%eax 0x0865f78a : cmp$0x,%eax 0x0865f78d : je 0x865f870 0x0865f793 : mov-0x3c(%ebp),%ecx 0x0865f796 : add$0xc,%edx 0x0865f799 : fldl -0x40(%ebp) 0x0865f79c : fstpl -0x20(%ebp) 0x0865f79f : mov%edx,-0x44(%ebp) 0x0865f7a2 : mov%ecx,-0x14(%ebp) 0x0865f7a5 : mov-0x40(%ebp),%ecx 0x0865f7a8 : mov%ecx,-0x24(%ebp) 0x0865f7ab : jmp0x865f7e8 0x0865f7ad : lea0x0(%esi),%esi 0x0865f7b0 : fldl (%esi) 0x0865f7b2 : fldl -0x20(%ebp) 0x0865f7b5 : fucompp 0x0865f7b7 : fnstsw %ax 0x0865f7b9 : sahf 0x0865f7ba : sete %al 0x0865f7bd : setnp %dl 0x0865f7c0 : and%edx,%eax 0x0865f7c2 : movzbl %al,%eax 0x0865f7c5 : test %eax,%eax 0x0865f7c7 : jne0x865f870 0x0865f7cd : mov-0x34(%ebp),%ecx 0x0865f7d0 : add-0x2c(%ebp),%ebx 0x0865f7d3 : mov-0x38(%ebp),%edx 0x0865f7d6 : and-0x30(%ebp),%ebx 0x0865f7d9 : lea(%ecx,%ebx,4),%eax 0x0865f7dc : mov(%edx,%eax,1),%eax 0x0865f7df : cmp$0x,%eax 0x0865f7e2 : je 0x865f870 0x0865f7e8 : cmp$0xfffe,%eax 0x0865f7eb : je 0x865f7cd 0x0865f7ed : mov-0x38(%ebp),%esi 0x0865f7f0 : shl$0x4,%eax 0x0865f7f3 : add-0x44(%ebp),%eax 0x0865f7f6 : add%eax,%esi 0x0865f7f8 : cmpl $0x7ff56789,-0x14(%ebp) 0x0865f7ff : jne0x865f7b0 0x0865f801 : mov-0x24(%ebp),%eax 0x0865f804 : cmp(%esi),%eax 0x0865f806 : je 0x865f870 0x0865f808 : mov-0x40(%ebp),%edx 0x0865f80b : mov-0x3c(%ebp),%ecx 0x0865f80e : mov%edx,(%esp) 0x0865f811 : mov%ecx,0x4(%esp) 0x0865f815 : call 0x8666810 0x0865f81a : mov0x4(%esi),%edi 0x0865f81d : mov(%esi),%esi 0x0865f81f : mov%edi,0x4(%esp) 0x0865f823 : mov%esi,(%esp) 0x0865f826 : mov%eax,-0x28(%ebp) 0x0865f829 : call 0x8666810 0x0865f82e : cmp%eax,-0x28(%ebp) 0x0865f831 : jne0x865f7cd 0x0865f833 : mov%esi,(%esp) 0x0865f836 : mov%edi,0x4(%esp) 0x0865f83a : call 0x8666850 0x0865f83f : mov-0x3c(%ebp),%edx 0x0865f842 : mov%edx,0x4(%esp) 0x0865f846 : mov%eax,%edi 0x0865f848 : mov-0x40(%ebp),%eax 0x0865f84b : mov%eax,(%esp) 0x0865f84e : call 0x8666850 0x0865f853 : mov-0x28(%ebp),%edx 0x0865f856 : cmp%edx,%edx 0x0865f858 : mov%edx,%ecx 0x0865f85a : mov%eax,%esi 0x0865f85c : repz cmpsb %es:(%edi),%ds:(%esi) 0x0865f85e : sete %al 0x0865f861 : movzbl %al,%eax 0x0865f864 : jmp0x865f7c5 0x0865f869 : lea0x0(%esi,%eiz,1),%esi 0x0865f870 : add$0x4c,%esp 0x0865f873 : mov%ebx,%eax 0x0865f875 : pop%ebx 0x0865f876 : pop%esi 0x0865f877 : pop%edi 0x0865f878 : pop%ebp 0x0865f879 : ret End of assembler dump. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ F
Re: [Flightgear-devel] simgear version number now a string
> It's a NaN! Sorry :) So now we know where all these NaN errors have been coming from! ;-) -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nan-a-palooza
Relying on undefined behavior is definitely no good...might work fine for a long time, but it will come back to bite you eventually. If you can find a way to do it in a compliant way without increasing the size would be ideal I guess, but if you need to increase the size so be it. Nasal is an integral part of flightgear and is so widely spread through every part of the sim it needs to be done properly and reliably. I'll be happy to test whatever you come up with. I personally will be very disappointed if all these nan issues continue into the next release... cheers! -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] ILS problem at EDDB
Start at EDDB and tune nav radio to ils frequency 110.70 fgfs: ../../../src/Instrumentation/navradio.cxx:920: double FGNavRadio::localizerWidth(FGNavRecord*): Assertion `rwy' failed. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ILS problem at EDDB
> Fixed in CVS now, thanks for the report. And thank you for the fix. :-) cheers -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat format
> Problem is that casting curved shapes into triangles, the way our > Scenery is currently set up, results in a pretty high triangle count. If your really using curves as input, you can sample as many...or as few points on that curve as you wish...hence as many or as few triangles you wish. There is no 1:1 mapping of curves to triangles..just sample at whatever resolution you wish. In x-plane the amount of points sampled can be configured at run-time by the users rendering preferences...he can control how many tris are generated and hence how smooth or coarse the curves will be represented. Since flightgear uses a static pregenerated mesh for terrain and airports we couldn't offer that dynamic lod like x-plane without so some major changes I think. However, in our case one 'can' just choose a reasonably coarse sample rate that does not result in an overly dense meshdoes not need to be perfectly smooth mesh / curve with millions of tris. No reason to sample hundreds or thousands of points for a 90 degree curve8-10 would probably look just finecertainly better than what we have currently. In other words..don't sample the curve every mm or cm...maybe every meter or two..or more...would have to experiment to find a good middle ground... cheers -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] New layout for KTEX
I've made a new and improved layout for KTEX. I used only USGS images for reference and eye balled it where necessary, so no worries about license or copyright or anything. If it could work it's way into the next scenery build that'd be great. File is attached...cheers! KTEX.dat Description: Netscape Proxy Auto Config -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] weather conditions and winds aloft not working correctly..
I seem to have a problem getting my weather conditions and winds aloft to behave correctly. I set weather scenario to disabled, input my weather and winds aloft data using the weather conditions dialog, but weather does not behave as input. The problem is especially apparent with winds aloft data, which does not pick up the winds aloft data correctly, and in many cases not at all. I input various wind directions, speeds, temperatures, etc for different altitudes (3000-15000ft in this case), yet when I climb to those altitudes and check the environment and other data I can see they are completely incorrect and not being honored at all. Entering the following for winds aloft for example: 15000ft -- 300 @ 16 12000ft -- 310 @ 14 9000ft -- 320 @ 12 6000ft -- 280 @ 10 3000ft -- 270 @ 9 I would expect if I am flying level at 12000ft for example, that I should encounter winds VERY close to 3...@14...yet I do not. Aloft layers seem to often not get picked up at all, or not picked up past the first or second aloft layer...becoming increasingly wrong the higher the altitude. Cruising at 12000ft example, changing the parameters for the 12000 layer has no effect at all, neither for surrounding layers 9000/15000...though sometimes changing the bottom layer (3000 in this case) does show immediate effect on aircraft...though the result is incorrect at 12000 obviously. I really don't see what I could be doing wrong, so one would have to think there is something very wrong in the environment code...? I get the same results in 2.0, cvs build (week or so before cvs death), and brand new up to date git builds. cheers! -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] weather conditions and winds aloft not working correctly..
On Tue, Jul 13, 2010 at 3:04 PM, Torsten Dreyer wrote: >> All I can say by now: it's most likely not a user error ;-) > Or is it? My first check was with fdm=magic to easily climb to any desired > altitude. This fdm does not update /position/altitude-agl-ft which is used to > interpolate through the environment layers. > > So _my_ check was based on user error and I can't verify what you have > reported, at least with a JSBSim aircraft, envirionment interpolation work > well here. > > To proceed, could you please specify: > which A/C (FDM) did you check with? > which properties did you check and found indicating false values? > > Thanks, Torsten > I've tried with numerous aircraft, both jsbsim and yasim...Lockheed1049H, pa22, velocity, and Tu154B to name a few. At first I noticed things not right when flying the Tu154B and just seeing the wind correction needle and ground speeds were not at all what I would expect them to be based off the winds aloft I had set up. I've since kept an eye on "/environment/wind-speed-kt" and "/environment/wind-from-heading-deg" when testing as well. I don't know if those are the best properties to look at, but they seem to be updated and interpolated when things are (at least partially) working. Besides the properties, just observing the incorrect ground speeds and course corrections compared to what is calculated for the winds I input is a give away something is not quite rightas well as nothing happening when I change the parameters in the gui as I mention before. I don't really know what to make of it...but hope solution can be found as I've started to grow tired of real-weather-fetch and would like to be able to set up more realistic (and less annoying) weather conditions, for longer distance cross country trips especially. cheers! -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] weather conditions and winds aloft not working correctly..
Not the best quality but readable, hopefully those will demonstrate the problems pretty clearly. http://www.flickr.com/photos/jmburbach/sets/72157624393619399/ I'm also unsure why you bring up altitude above ground, as winds aloft are stated above sea level and in true headings are they not? cheers -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] weather conditions and winds aloft not working correctly..
Ok, quick test with a new pull and it seems like heading and speeds are working for the layers now. The temperatures don't seem to be taking though, same setup as previous and I was below zero celcius before reaching 9000 feet and already nearly 9 below celcius at 12000 feet. Not sure about other settings, dewpoint, turbulence, etc, didn't play with those yet. I did notice altimeter wasn't coinciding with the input valuesthough to be honest I'm not sure I fully understand how the altimeter values are supposed work over altitude, temperature, etc changes...in flightgear or real life. cheers -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] weather conditions and winds aloft not working correctly..
> For the time being, entering temperature into the dialog box is broken. The > only way to set a temperature is by setting /environment/temperature-sea- > level-degc which calculates the temperature at altitude based on ICAO standard > atmosphere. That's a little disappointing. Hopefully a better way to do things can be found as from what I can see the calculated temperatures are nowhere close to actual aloft data. Anyway, thanks a bunch for working on this, weather is a very important part of aviation and flight planning so anything that can be fixed or improved is always good. On a side note...is there a way to retrieve a list of airports within a certain distance of a position from nasal? cheers! -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] weather conditions and winds aloft not working correctly..
On Mon, Jul 19, 2010 at 3:47 AM, James Turner wrote: > > On 19 Jul 2010, at 01:47, Jacob Burbach wrote: > >> On a side note...is there a way to retrieve a list of airports within >> a certain distance of a position from nasal? > > Trivial from C++, unfortunately tricky from Nasal right now. This needs an > extension or alternative to airportinfo(), which allows the 'range' parameter > to be tuned. How urgent is the need? > > James It's not very urgent for me personally as what I'm doing can be done a different way, but it could be quite useful in a number of situations though. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] weather conditions and winds aloft notworking correctly..
Thanks for the quick work on this Torsten...with the exception of dew point and altimeter settings everything else appears to be working properly now. Currently I don't think dew point and altimeter are a big deal for what I'm doing personally, but they are/were seemingly intended to work so should probably be addressed as well. Thanks again, cheers! --Jacob -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Serial port programming question ...
> I know I can use select() to check if the file descriptor is ready for a > write(), but that would still not be a way to determine if the file > descriptor is ready for the size of my particular write() and ensure that my > write() will return in a timely fashion ... it seems like it would still > leave me open for potential trouble or potential unwanted time delays. > I'm no expert and can't answer all your questions or give best design advice...but. If your using non blocking IO and select signals a write is available, then that write should always return in a timely fashion. Like you said there though, select won't tell you how much can be written, nor does the write call guarantee it will write everything you give it. As usual when doing non-blocking asynchronous type stuff, it will be up to you to do the book keeping and send any remaining data in subsequent writes. Though I seem to recall there may be some ioctl calls available that actually tell you how much data is ready for reading or writing on a file descriptor, but can't recall off hand...may well be platform/os/arch specific. cheers -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] development directory
I also needed to add an entry in Nasal/IOrules to allow reading in my custom aircraft directories when using this in order for most aircraft to load properly. This should be changed imho as IOrules has a READ entry for $FG_AIRCRAFT/* already, and I would think explicitly added aircraft directories should get covered by that..no? Unless I've completely missed something of course..in which case feel free to disreguard... cheers --Jacob -- Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] development directory
Apologies, looks to be a misunderstanding on my part. I was putting `--fg-aircraft=/some/path/Aircraft', when it seems I should have just been putting `--fg-aircraft=/some/path'. Using the latter and permissions work properly, the former needs the path in IOrules and then it will also work apparently. So yeah, bit of user on my part. :) -- Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] development directory
I think what kind of through me off was that the aircraft loads either way you give it the path. Except in the case of giving it an Aircraft directory directly as I was doing, and for aircraft that make use of IO functions in nasal, I would get lots of permissions errors and aircraft would be missing functionality. So rather than realizing I was giving it improper paths, my initial thought was that I need to add permission entries to make it work...which seemed odd..but does work. So current implementation is probably just fine, but maybe the help text and/or other docs should be more explicit about what kind of path it expects? cheers! -- Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Comments and questions about model loading, model formats, and effects....
Hi all, I'm experimenting with various model file formats and the effects system and have some questions/comments. First I found that if you have a file 'model.ac', but also have a file 'model.osg', flightgear always loads the .osg version despite me explicitly requesting the '.ac' in the models xml file. Personally I don't see any point in automatically choosing one text based format over another, especially when I explicitly told the system I want the '.ac' via the model xml. So yeah is this considered some sort of feature..or just a bug...because it only served to frustrate me and waste my time until I realized what it was doing. Second up is does the effect system not work with anything other than '.ac' file format? With '.ac' my effect is loaded, using any other format I tried (.osg, .ive , .osgb, .osgt) the effect seems to be ignored. Is the effect system currently crippled to using only the ac3d format, or what's going on here? cheers! -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....
> This is considered a "feature," by some anyway :) I added this with the idea > that one could optimize ac model and substitute the optimized version. It's > never been used much and has led to complaints about getting the wrong cows. > I still think the idea is a reasonable one, but perhaps it needs to be > removed in its current form. Personally I think it's better that if I specify a certain file to be loaded that it is honored, rather than having something trying to be clever and second guess me in the background. > Effects only work with .ac files because the code knows how to extract > material parameters from the loaded representation of the .ac files. Those > parameters are used by the default effects in the Effects folder. It should > be possible to apply a complete effect with no missing parameters to a > named object in a different kind of file, but I haven't tried it. > Tim Damn, was hoping I was just doing something wrong...I really need this. I think we should at the very least support OSG native formats (osg,ive,osgb,osgt). But really, shouldn't we get be reading the pertinent data from OSG interfaces after the plugin has loaded it up, rather than doing file specific stuff at all? I thought that was the whole point about all the osg loaders...to abstract that stuff away as much as possible. So what can I do to help move this along? I do really need it for my projects as the ac3d format just doesn't cut it for me. cheers! -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....
On Sun, Dec 12, 2010 at 5:50 AM, Tim Moore wrote: > That depends on whether you view fgfs as a model preview tool or as a > real-time program. I don't mean to be snarky in saying that; as hardware > improves, the balance between what should be done before runtime and what > can be done at model load time changes. But I think you can see that, for > optimal real-time performance, it would be best to load an optimized form > of a model. I do agree it is important to use models and even file formats optimized for performance. I believe however, that those optimizations should be done in the content creation suite itself and/or when exporting the model to its final format used in engine. Not to say the engine couldn't try to do some extra optimization after loading a model, and even cache that loaded data somewhere for reuse, say a fast binary cache for example. However it should always load the artist specified file first, and reload / recache it any time that source file changesnot just arbitrarily pick a different file behind the scenes. I don't mean to be overly critical or put down someones hard work or anything, but you said yourself it was a feature rarely used and often complained about. >> Damn, was hoping I was just doing something wrong...I really need >> this. I think we should at the very least support OSG native formats >> (osg,ive,osgb,osgt). But really, shouldn't we get be reading the >> pertinent data from OSG interfaces after the plugin has loaded it up, >> rather than doing file specific stuff at all? I thought that was the > > Yes, and of course we do that. .ac is a very simple format, so it is easy > to walk the graph of a loaded .ac file and extract the material and texture > bindings. This becomes much harder as you move to the general OSG formats, > as these bindings could be anywhere in the scene graph, above or below the > named objects. .osg files can even contain their own "effects" in the form > of shader programs or osgFX nodes. Of course it's probably not just a simple task, and I didn't mean to try and trivialize it by just saying 'use osg' data. I do believe it is quite important for content creators to have access to smaller, faster, and more capable (preferably binary) file formats. The ac3d file is nice that it's simple and human readable and so on, but it's also very a limited format, and does not scale well at all with more complex and larger models and techniques. >> So what can I do to help move this along? I do really need it for my >> projects as the ac3d format just doesn't cut it for me. >> > Look at the source in simgear/scene/model, find where it looks for .ac > files, and change it. modellib.cxx:143, for example. > Tim Will do. I take it your the maintainer/creator of this particular bit of code then? I feel this is very important for the future of fgfs graphics and performance wise and I'm quite willing to put in some work to make it happen. I do need to know there is support for this idea to be rolled into fgfs though, that I won't be wasting my time for something that won't be used...or not receive any support on. thanks! --Jacob -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....
On Sun, Dec 12, 2010 at 10:51 AM, Curtis Olson wrote: > On Sun, Dec 12, 2010 at 9:21 AM, Jacob Burbach wrote: > Would it be possible to come up with our own optimized model extension that > would be unique and different from anything an artist might produce? I > could see this heading off into a lot of work though. We maybe would want a > global flag that specifies if model optimization should be turned on / off. > Saving an optimized version of every model could significantly increase the > harddrive footprint of our data tree. > Just thinking out loud here ... > Curt. Also thinking out loud... First thing to do in my opinion would be to put the ac3d format to rest and focus on one single, feature rich, capable, and portable format for fgfs content creators to work with. I think collada is probably an obvious choice for this. Then... a) Load the collada (or whatever) file directly, automatically caching it to native format / global cache somewhere for reuse. The loader would then check the cache first to see if a file is already there and load it from there, if not or if the source file has changed reload it and (re)cache it. This has advantage that content creators could just work with one format and everything else happens automatically behind the scenes without need to think about it. This also has disadvantage that when a user first loads new content (aircraft, scenery, etc) performance will be bad that first time as you have to load unoptimized and large files and then cache them. There is also the problem of content that is removed, still existing in cached form, and the amount of disk space needed growing much larger as you now, in some form or another, have multiple versions of the file in question on your disk. b) Provide a fgfs converter tool that takes the collada (or whatever) file the content creator works with and creates the fgfs native format out of it which can then be used by flightgear. This has the advantage that your always loading the native optimized format, there is no worry about how to handle caching in the background, or large amounts of space used for the cache, or how to hand orphaned items in the cache..etc. Also by having the converter provide various options for the content creator to enable/disable etc one puts more power in the content creators hands which is usually a good thing. Couple disadvantages would be that; 1. content creators have to convert the stuff before using it or distributing it, and 2. that end users get a native format they can't modify directly. Number 1 is not really a huge deal at all though, and could be easily automated too. Number 2 is easily addressed by simply having the fgfs converter tool work in both directions. Run the converter on the collada (or whatever) and you get the fgfs native format for distribution, run the converter on the native file and converts back to the collada (or whatever) format for import into your content creation app of choice for editing. I kind of prefer option b, as I think it provides the most flexibility for artists, simplicity for the engine, and no worries about larges amounts of space used by a global cache or secondary files, etc. That said, anything like that sort of thing would obviously take a lot of planning, work, and time to complete. Even if it was decided to go in that direction for the future, I think it would be important to allow for other formats than ac3d to work properly with the material/effects system first, so we have some much needed ability and performance possibilities in the short term. cheers --Jacob -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....
Well, just adding the .osgb extension in modellib.cxx is not enough to trigger effect loading for it...no surprise I guess that some extra processing is needed in other places as well. Hmm, having to reverse engineer a bunch of undocumented model and effects code in simgear, as well as also learning and tracking osg calls doesn't sound very productive. So if someone familiar with the model loading and effects system would be kind of enough to fill me on the general flow of how things are loaded, what's required to extend it for other formats, what the effects system needs to work proper with it and so on I would really really appreciate it. thanks --Jacob -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....
On Mon, Dec 13, 2010 at 1:26 AM, Tim Moore wrote: > I wrote the effects framework and am interested in improving it, of course. > I can't guarantee in advance that any particular work will be committed, so > you should undertake any hacking to fulfill your own needs and not solely > because you think it will be committed. I'm willing to help if you want to > dive in. > Tim Of course I won't expect you to commit to adding any code I write, sight unseen and untested. As long as I know there is support for the idea from those maintaining that code and no one is against it I'm comfortable putting in the time. The project(s) I'm working on are for the community though, meaning they are and will be distributed freely to all users...so of course the functionality would need to be a core part of flightgear to be at all useful. But yeah, don't expect you to totally commit to adding something that doesn't yet exist... The major project I'm working on at the moment is the custom scenery for Innsbruck. And by custom scenery I don't mean just some airport models and a few landmarks and putting them in the db. I'm talking about a full fledged, highly detailed, very complex and complete scenery package...roads, highways, power lines, entire villages and cities accurate to real life. Think along the lines of something you expect from a payware scenery add on in one of those other flight sims. A lofty goal yes, but I'm confident in my abilities to achieve it as time permits, and have already committed more than a year to get to the current point. However to achieve such a goal, on such a scale, I'm really having to work outside the box. The standard and accepted flightgear way of single objects in ac3d format submitted to the database just won't work for this type of project. I am designing and modeling very large static geometries that fit to the terrain accurately. While ac3d format works 'ok' for simple models and techniques...it does not scale well for very large and detailed objects. The file size alone is a drawback, along with export times, load timesand the fact it doesn't support basic things like multiple texture coordinates / texture units. So what I really need, and what would benefit flightgear as a whole in long term, is a fairly efficient binary format that supports such features. Of course we can already load these formats and use them, and I am as best I can, but they aren't fully supported by flightgear yet as they could be / need to be. The classic flightgear xml material animations for example doesn't know anything about multiple texture coords, texture units, and so on...so we need (and prefer anyway) the modern material effect and shader support system you've designed in order to use these formats and features properly. Well, I feel I'm rambling on a bit again, but I hope that it at least makes it somewhat clear what I'm trying to achieve and why, and why I need the functionality I'm looking for. You can check my Innsbruck thread in the scenery section of the forums if your interested in details, methods, techniques, and tools I'm exploring for this...or just ask. > I'm willing to help if you want to dive in. Thanks Tim, I will be diving in so expect some questions and such in the near future. ;-) thanks...cheers! --Jacob -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] decoding coordinates of a particular tile
I wonder if someone could give me a hand with this to make sure I do it correctly. I'm trying to decode the coordinates of a given scenery tile so I can create a kml file for visualization purposes. Based off the btg importer on the wiki and the calc-tile.pl script I've put together this bit of code here. http://pastebin.com/gG6BfdWu I believe it does the correct things, it matches what the exporter spits out anyway. Could anyone confirm if this is indeed properly decoding the tile coords? Also about the x and y values, it's the position of the tile in a grid that makes up the region? Where is the origin of the grid then, I assume the lower left / south west...x increasing longitude and y increasing latitude or? And lastly what is correct way to get the coordinates of each corner of a tile...should I just add or subtract half span from the center coordinates like so min_lat = center_lat - (span * 0.5) min_lon = center_lon - (span * 0.5) max_lat = center_lat + (span * 0.5) max_lon = center_lon + (span * 0.5) or...? thanks --Jacob -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] decoding coordinates of a particular tile
Thanks Ron. Your snippet of course points out the obvious that I could just look at the simgear source for details...and I did find the answers I was looking for there. Time to get away from the pc for a while I think cheers! -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] decoding coordinates of a particular tile
Thanks guys. After poking around the sgbucket code a bit I fixed everything up and made it work well enough to generate a kml for the area I'm interested in. http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=http:%2F%2Fdl.dropbox.com%2Fu%2F15218376%2Ftile.kml&sll=37.0625,-95.677068&sspn=40.409448,93.076172&ie=UTF8&ll=47.565407,12.409058&spn=2.157209,5.817261&t=k&z=8 Red border is the 1x1 degree chunk, white grid is of course the tiles inside that chunk. Now I can visualize exactly what lies within each tile and how flightgear will be loading and unloading my scenery. I'll be using this to decide how to best partition up the static geometry in my Innsbruck scenery project for performance and so on. cheers! -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....
Ok then, trying to make sense of this whole model & effects loading code... In `modellib.cxx' the `loadFile' and `loadModel' functions, which check the file extensions for a `.ac' file and if so sets a flag for instantiation of effects. This flags is only checked in the 'ACOptimizePolicy::optimize' method in `ModelRegistry.cxx' and appears it's only purpose is to make sure non xml wrapped `.ac' files get the default model effect applied. This is done by calling an overloaded `instantiateEffects' function in `model.hxx' that simply calls the other version of the function with an empty effects property tree causing default model effect to get used. Ok... Now models wrapped in xml (and thus any model with an effect attached) of course don't get any flags set in the `load*' functions and go a whole different path...through `SGReaderWriterXML' and friends. So then `sgLoad3DModel_internal' from `SGReaderWriterXML' seems to handle most the heavy lifting of parsing the xml file including any `' elements, and then itself calls `instantiateEffects'. In this case though it calls the non overloaded version and passes in any effect properties it found...which if there were none again causes default model effect to get applied. Now, in this xml loading path any models loaded from inside it, `.ac' or otherwise, never find there way to the `load*' functions in `modellib.cxx' thus never getting the instantiate effect flag, thus ensuring that `ACOptimizePolicy' (which does still get called) doesn't call the overloaded `instantiateEffects' since xml loader will call the non overloaded itself. Phew.. So here is the kicker...`instantiateEffects' does indeed seem to be called for every single model wrapped in an xml regardless of whatever format that might be. So then it seems the effect code is simply failing silently on non ac3d formats. Perhaps in the `MakeEffectVisitor' or further up the chain somewhere who knows...deeper down the rabbit hole we go... So umm Tim...could you maybe explain the process of the whole model loading, getting effects applied, what the effects system expects from a model, the reasoning behind it and so on? There is a lot of static local functions and classes and so on in this code that is completely undocumented and not at all trivial to unwind and try and fit the pieces together. Would be really, really helpful if you could lay out the code flow here, what functions are involved and inter-dependent on each other, what processing is needed for the effect system to work, etcin the mean time I'll keep digging. cheers! --Jacob -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....
Hey thanks for taking the time to respond, especially during the holidays. So what I see currently in the model loading code in regard to effects is really something just hacked together to 'get er done' and make it work. Which is fine of course, but I think we can do better and I really believe we can do this in a general fashion that should work for all model formats...but still allow specific processing if needed. I mean yes, each model loader may organize a models scene graph a bit differently...but the effects/material system is only concerned with state sets and geode/geometry for it's purpose. And OSG makes it very easy to drill down through a scene graph to find those particular things so there really shouldn't be a problem here. Not to say that it will be trivial of course, but certainly doable. I'll be working on it when things settle down after the holidays and will of course be bouncing ideas and design stuff at you so we can find the best way to get it done and into flightgear. > I recommend you use the osgconv program to dump out the .osg representation > of our .ac models and the models that interest you and get > an idea of the differences you are up against. Already been doing this, along with writing some code using OSG to load/texture my model and dump them out to see how I can define more advanced techniques in the model files. I currently have multiple models in my scenery in osg2 binary (.osgb) format making use of multiple texture units and texcoords, some texenv stuff, and also some very nice anisotropic filtering ;) Of course it would be much better if I could make use of flightgears material system, interface with flightgear properties, and. cheers! -- Forrester recently released a report on the Return on Investment (ROI) of Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even within 7 months. Over 3 million businesses have gone Google with Google Apps: an online email calendar, and document program that's accessible from your browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Some community comments
> However, with the exception of scenery models, no one is really developing > anything new - just using existing data and programs to create the sceneries > without much apparent thought to topology. Can you elaborate on that last part, about topology? cheers -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Some community comments
On Wed, Dec 22, 2010 at 1:39 PM, Martin Spott wrote: > > Being honest: I don't care. If people think that following a cooking And to be honest I don't understand why you started this discussion with such obvious trolling behavior and comments such as these? > recipe is their cup of tea, then I'm fine with it. If they call this > "Scenery development" and behave like having reinvented the wheel, then > they're invited to reflect my comment. Now usually I just ignore you completely because I know from past experience are personalities don't mesh well, and I'll probably regret responding to you this time..but this is ridiculous. There are relatively few of us creating custom scenery from Corine and/or other data and making it available...I can seriously count them on one hand. Those few individuals, myself included, simply do not go around pretending we have reinvented the wheel or anything like that...nor are we looking for some ooh & ahh factor. I personally am very open about what data I'm using, methods and tools I used, and have also made it quite clear on numerous occasions I'm not doing anything particulary noteworthy or new when it comes to generating the scenery from said data. We are simply trying to create the best scenery possible for ourselves and to the community at large ...to suggest otherwise is simply false. --Jacob -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Some community comments
>> [...] Still, none of the third party sceneries directly help the goal >> of adding data to the server or helping fix TerraGear to push out a >> new World Scenery package [...] I think the key word here is "directly". No, they may not, even cannot, "directly" contribute land cover to the data server...and why should they need to anyway? In almost every case everyone has access to that same data and if there is no conflicting license issues (and there are) then it can/should already be in the global db by those maintaining it. However, I believe these projects do contribute to the community and the project by showing people flightgear is capable of having nice looking and accurate base scenery, by taking the time to generate that scenery and provide it freely to everyone for use, and also inspiring further scenery work in that area that "does" make it into the global scenery db. --- --- Maybe it's not every ones cup of tea, not aligned exactly with "their" goals or wishesbut I know for a fact a very large number in the community greatly enjoy and appreciate these third party scenery projects. If you don't like it, don't use it, but there is no need for anyone to be a complete douche bag trolling the list critizing other peoples hard work and personal projects. Should we start pissing on third party aircraft as well? Want to piss on Yuriks hard work, or maybe Garys, since the Tu154b and Constellation and others are not in the git package, maybe not licensed to match the git package, and/or just plain better than what's in the git package? There are reasons people may choose to develop as a third party, whether it be scenery, aircraft, or even code. Who are you to criticize them, or make false accusations about how they act, why they do it, or to what level of quality they do it? I have a goal with my own third party Innsbruck scenery project, and have been very open about that goal, the methods and tools I'm using and developing to achieve it, and why I'm doing things the way I'm doing them. If you don't like it, don't use it, no one is forcing you to use it or any other third party project. To criticize other peoples work just because they don't align exactly with your vision, your project, or whatever your real personal reasons..is just petty and plain old fashioned douche baggerygrow up. cheers --Jacob -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Some community comments
On Thu, Dec 23, 2010 at 12:29 PM, J. Holden wrote: > I appreciate the ephithet being hurled in my direction, especially because > all we are pointing out is that CORINE data should eventually be part of the > land cover database anyways, which may deprecate some (but not necessarily > all) of the third-party scenery projects currently being produced, > > Cheers > John Exactly. If a project is just terrain generated using whatever data, and that data becomes part of the official DB then that project will have served its purpose and can fade away. In the mean time, while we wait for that day, those projects are very well accepted by the community at large, make flightgear look good, generate interest flightgear and in developing those areas furtherit's a "good" thing. When the time comes those projects become unnecessary I think you'll find most/all the creators of that scenery will probably happy with that fact...as processing, generating, and distributing very large sets of terrain is quite time consuming and not all that trivial. cheers --Jacob -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor menu renaming
On Sat, Dec 25, 2010 at 6:54 AM, Gijs de Rooy wrote: > Looks good to me Stuart! But I do wonder why people feel the need to > capitilise each single word. > Why isn't it "Traffic options", or "Tanker controls"? I know it's not a big > deal, but to me it looks > cleaner and clearer... > > If we change it, we should do it for all menu items at the same time though, > so there's some sort > of uniformity. I volunteer for doing that, if there's support for it ;) > > Cheers and merry Christmas! > Gijs I'm not really partial to one way or the other, and I believe guidelines vary across platforms and such so I think either is fine. I am a believer in consistency though, so I'm definitely in support of making sure they all match. cheers...happy holidays! --Jacob -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bug in model collision detection?
I'm having some trouble with collision detection not working properly on some models I'm working on. The models are made of a few different objects and while everything else works normally collision detection is not working on all the objects. I've attached a test model that illustrates the problem for me. Place the model somewhere (with ufo or whatever) and then try to fly aircraft through the different objects of the model. Here only the large box in the middle actually collides, and either of the smaller upper and lower objects I can simply pass through. Am I missing something obvious, is this a bug somewhere? cheers test.ac Description: Binary data test.ac -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug in model collision detection?
On Tue, Dec 28, 2010 at 1:32 PM, Vivian Meazza wrote: > Collision detection? Er - we don't really have that. There is Height Over > Terrain (HOT), which is on for scenery and AI objects by default, but not > for Aircraft models. This will enable you to land on a building, but usually > lets you fly through the walls, although you might also appear to collide > with it. By collision detection I was indeed referring to HOT functionality. I was not referring to aircraft models as I'm aware there is no "collision" or anything with those. I usually have no problems with being able to fly through walls or any other solid object. Usually causes a "collision" and aircraft to crash unless the geometry is very small. Does depend on aircraft, some work better than others of course. In this case the geometries above and below the central geometry have no "collision" whatsoever, while the central geometry itself does "collide" and cause a crash. > In any case the ufo can fly through anything: land - sea - buildings ... I'm quite aware the ufo can fly through anything...which is why I said to place the model and then try flying an aircraft through it. ;) cheers -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Latest git results in massive NAN errors with Tu154B
Updated my copy yesterday and now I cannot load flightgear with the Tu154B anymore. Trying just results in massive amounts of NAN errors and crash. Looks like the entire property tree and everything else got NaNifiedsee log. Anyone have any clues what may have changed to cause this? Aircraft hasn't changed in months and has always worked perfectly with git until this fresh build yesterday. log is here http://pastebin.com/utrUVmeu (would attach but got rejected by list mod) cheers -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest git results in massive NAN errors with Tu154B
On Sat, Jan 8, 2011 at 9:59 AM, Curtis Olson wrote: > Hi Jacob, > The tu154 appears to be working fine for me here with the latest git as of > Saturday morning. You might try doing a make clean and rebuild for > simgear/flightgear just to rule out that there isn't any weirdness that has > crept into your local tree, or maybe something got out of sync between > system updates and flightgear/simgear code updates. > Regards, > Curt. Hmm, I'll try again to be sure, but I always do a make clean && make install whenever dealing with simgear/flightgear because of issues in past. Also just to be clear I am referring to the Tu154B from Yurik, not the old Tu154 in the flightgear repository. http://yurik.flightgear.ru/tu154b-release/tu154b-1.0_jun2010.tar.gz svn://hlserver.lin.irk.ru/trunk/TU154B cheers -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest git results in massive NAN errors with Tu154B
On Sat, Jan 8, 2011 at 12:24 PM, Curtis Olson wrote: > Oh, then I don't know ... I've always lived in the world of our git aircraft > and haven't gone out and tried any of the 3rd party aircraft. (And sorry to > waste a message saying "I don't know" ...) > Regards, > Curt. Too bad, if that's true your missing out on a few of the best aircraft flightgear has to offer. ;-) Well, I know others fly it, and links are there for anyone else who wants to take ten minutes to test it out. Personally I'd be concerned about the possibility that something has changed that could trigger such a massive nan breakage with a release nearing, regardless of the aircraft origin...but to each his own. cheers -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
