Re: [Flightgear-devel] Improving random trees & buildings
2011/12/29 Mathias Fröhlich : > > And this is what I try to do now: > Object against using these patented compression algorithms. > I do not care for the on disk format of any image file we have. But the > problem > is that some kind of precompression that can be stored in these dds files > cannot be used with other drivers than the closed ati and nvidia ones. > As long as these patented compression techiques are not used, every OpenGL > driver can use this and displays this fine. I agree fully with Mathias on this issue, even though I am using the binary fglrx at the moment. I check the open source one from time to time, however, to see if it has improved enough for my purposes. Incidentally, AMD's favorable open source policy was the reason I switched from nVidia. I wonder if there is an open standard counterpart that can do the same as the dds compression? Or is the whole idea patented? (Eww, too broad software patents are the work of the devil). -- Csaba/Jester -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Debugging an Ati shaders issue (with 3d textures, again)
On Wed, Dec 28, 2011 at 5:22 PM, James Turner wrote: > > Csaba, since you have the same card as me, but are not seeing this issue, > what limit are you getting for GL_MAX_TEXTURE_UNITS_ARB? (From the fglrx > driver, I guess) My limits differ in a few places from yours, sometimes better sometimes worse. The TEXTURE_UNITS stuff is the same, but the TEXTURE_COORDS aren't - where you have 8, I have 16. I wonder if that could be significant? Full list follows: OpenGL limits: GL_MAX_ATTRIB_STACK_DEPTH = 16 GL_MAX_CLIENT_ATTRIB_STACK_DEPTH = 16 GL_MAX_CLIP_PLANES = 8 GL_MAX_COLOR_MATRIX_STACK_DEPTH = 10 GL_MAX_ELEMENTS_VERTICES = 2147483647 GL_MAX_ELEMENTS_INDICES = 16777215 GL_MAX_EVAL_ORDER = 40 GL_MAX_LIGHTS = 8 GL_MAX_LIST_NESTING = 64 GL_MAX_MODELVIEW_STACK_DEPTH = 32 GL_MAX_NAME_STACK_DEPTH = 64 GL_MAX_PIXEL_MAP_TABLE = 256 GL_MAX_PROJECTION_STACK_DEPTH = 10 GL_MAX_TEXTURE_STACK_DEPTH = 10 GL_MAX_TEXTURE_SIZE = 16384 GL_MAX_3D_TEXTURE_SIZE = 8192 GL_MAX_VIEWPORT_DIMS = 16384, 16384 GL_ALIASED_LINE_WIDTH_RANGE = 1, 128 GL_SMOOTH_LINE_WIDTH_RANGE = 1, 63 GL_ALIASED_POINT_SIZE_RANGE = 1, 8192 GL_SMOOTH_POINT_SIZE_RANGE = 1, 63 GL_MAX_CUBE_MAP_TEXTURE_SIZE_ARB = 16384 GL_NUM_COMPRESSED_TEXTURE_FORMATS_ARB = 20 GL_MAX_TEXTURE_UNITS_ARB = 8 GL_MAX_TEXTURE_LOD_BIAS_EXT = 16 GL_MAX_TEXTURE_MAX_ANISOTROPY_EXT = 16 GL_MAX_DRAW_BUFFERS_ARB = 8 GL_MAX_CONVOLUTION_WIDTH/HEIGHT = 11, 11 GL_VERTEX_PROGRAM_ARB: GL_MAX_PROGRAM_INSTRUCTIONS_ARB = 2147483647 GL_MAX_PROGRAM_NATIVE_INSTRUCTIONS_ARB = 2147483647 GL_MAX_PROGRAM_TEMPORARIES_ARB = 320 GL_MAX_PROGRAM_NATIVE_TEMPORARIES_ARB = 256 GL_MAX_PROGRAM_PARAMETERS_ARB = 256 GL_MAX_PROGRAM_NATIVE_PARAMETERS_ARB = 256 GL_MAX_PROGRAM_ATTRIBS_ARB = 29 GL_MAX_PROGRAM_NATIVE_ATTRIBS_ARB = 32 GL_MAX_PROGRAM_ADDRESS_REGISTERS_ARB = 1 GL_MAX_PROGRAM_NATIVE_ADDRESS_REGISTERS_ARB = 1 GL_MAX_PROGRAM_LOCAL_PARAMETERS_ARB = 256 GL_MAX_PROGRAM_ENV_PARAMETERS_ARB = 256 GL_FRAGMENT_PROGRAM_ARB: GL_MAX_PROGRAM_INSTRUCTIONS_ARB = 2147483647 GL_MAX_PROGRAM_NATIVE_INSTRUCTIONS_ARB = 2147483647 GL_MAX_PROGRAM_TEMPORARIES_ARB = 320 GL_MAX_PROGRAM_NATIVE_TEMPORARIES_ARB = 256 GL_MAX_PROGRAM_PARAMETERS_ARB = 256 GL_MAX_PROGRAM_NATIVE_PARAMETERS_ARB = 256 GL_MAX_PROGRAM_ATTRIBS_ARB = 29 GL_MAX_PROGRAM_NATIVE_ATTRIBS_ARB = 16 GL_MAX_PROGRAM_ADDRESS_REGISTERS_ARB = 0 GL_MAX_PROGRAM_NATIVE_ADDRESS_REGISTERS_ARB = 0 GL_MAX_PROGRAM_LOCAL_PARAMETERS_ARB = 256 GL_MAX_PROGRAM_ENV_PARAMETERS_ARB = 256 GL_MAX_PROGRAM_ALU_INSTRUCTIONS_ARB = 2147483647 GL_MAX_PROGRAM_TEX_INSTRUCTIONS_ARB = 2147483647 GL_MAX_PROGRAM_TEX_INDIRECTIONS_ARB = 2147483647 GL_MAX_PROGRAM_NATIVE_ALU_INSTRUCTIONS_ARB = 2147483647 GL_MAX_PROGRAM_NATIVE_TEX_INSTRUCTIONS_ARB = 2147483647 GL_MAX_PROGRAM_NATIVE_TEX_INDIRECTIONS_ARB = 2147483647 GL_VERTEX_SHADER_ARB: GL_MAX_VERTEX_UNIFORM_COMPONENTS_ARB = 16384 GL_MAX_VARYING_FLOATS_ARB = 128 GL_MAX_VERTEX_ATTRIBS_ARB = 29 GL_MAX_TEXTURE_IMAGE_UNITS_ARB = 16 GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB = 16 GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB = 32 GL_MAX_TEXTURE_COORDS_ARB = 16 GL_FRAGMENT_SHADER_ARB: GL_MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB = 16384 GL_MAX_TEXTURE_COORDS_ARB = 16 GL_MAX_TEXTURE_IMAGE_UNITS_ARB = 16 -- Csaba/Jester -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Debugging an Ati shaders issue (with 3d textures, again)
On Wed, Dec 28, 2011 at 5:04 PM, Frederic Bouvier wrote: > Hi James, > >> De: James Turner >> >> So, what's the next step in understanding this? The effect claims to >> use the noise texture (in unit 9, as always): >> >>OpenGL limits: > ... >> GL_MAX_TEXTURE_UNITS_ARB = 8 > ... >> GL_MAX_TEXTURE_COORDS_ARB = 8 > > It looks like the texture unit of the noise texture is beyond the limits of > your card Since we are talking about shaders, aren't the limits GL_VERTEX_SHADER_ARB: GL_MAX_TEXTURE_IMAGE_UNITS_ARB = 16 GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB = 16 GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB = 16 GL_FRAGMENT_SHADER_ARB: GL_MAX_TEXTURE_IMAGE_UNITS_ARB = 16 instead? -- Csaba/Jester -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ..is only the "explicit data-dir" checked for udev??? FG builds now fail.
On Mon, Dec 26, 2011 at 12:42 AM, Arnt Karlsen wrote: > Hi, > > ..is only the "explicit data-dir" checked for udev??? > Or did I miss something else? As far as I can see, udev is not the reason for the failed build, X11_Xft_LIB and X11_Xinerama_LIB are. Cmake is only nice as long as it is working, it's a nightmare to troubleshoot ... -- Csaba/Jester -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Live Multiplayer
On Sun, Dec 25, 2011 at 2:20 PM, Geoff McLane wrote: > > It would certainly be nice to have a 2nd, or more, > servers, like say fgcom.fgx.ch:16661, or on any other > port, that can be used with the fgcom client, or in > the fgcomgui... > > Then we would not be dependent on just one IP ;=)) > Although I must say I have never yet found the above > IP down... > > And then there would be the question of how such > multiple fgcom (asterisk) servers interact, such that > even if I configure using say 'ch' I can still 'speak' > to pilots using the 'uk' server... etc... another can > of worms ;=)) At times, we had 2 servers but only one active with manual switching when necessary. That means there is no load balancing among multiple servers. In case anybody wants to volunteer maintaining a backup server, I am sure we can collect the knowledge required to set it up and fill in the holes in the wiki. I'd like to thank all the people who keep fgcom alive behind the scenes, in particular Charles, Jon, Thomas, Willie and of course Holger for creating it. -- Cheers, Csaba/Jester -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Debugging an Ati shaders issue (with 3d textures, again)
On Fri, Dec 23, 2011 at 5:05 PM, James Turner wrote: > I'm having the dreaded 'invalid operation after ' errors from OSG, which > makes seeing other debug output. Once again, it relates to 3D textures, and > is presumably Ati specific. > > Details: > - latest Git of fg+sg+fgdata, OSG 3.0.1 > - card is a Radeon 5770, with the official Apple drivers, info strings > says: > ATI Radeon HD 5770 OpenGL Engine > 2.1 ATI-7.12.9 > - c172 or UFO at EGPH, traffic enabled > > At shaders quality = 0 or 1, I do *not* get the message - at quality level 2 > or higher, I do. Just as a data point: HD5770 here too, but linux fglrx. I don't see such messages, up to quality level 3. Anything higher causes lock-up of FGFS (have to kill it). -- Csaba/Jester -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] deteriorating cull performance kills fps
2011/12/21 Mathias Fröhlich : > > Yes, I saw this a few weeks ago on a long flight. > But I did not see a chance to reproduce what I saw. So I did not look > closer... Seems to be gone now :) Any comments for my other question, about background model loading? -- Csaba/Jester -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] deteriorating cull performance kills fps
Recompiled with fresh OSG/SVN and cull times were now stable at least for the duration of the 30 minute parked test. I will re-enable eye candy and do some flights tomorrow, but I hope the mysterious problem is fixed. -- Csaba/Jester -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] deteriorating cull performance kills fps
On Wed, Dec 21, 2011 at 12:42 AM, Csaba Halász wrote: > On Sun, Dec 18, 2011 at 5:31 PM, Csaba Halász wrote: >> On Sun, Dec 4, 2011 at 6:00 PM, Csaba Halász wrote: >>> >>> I know this information is very sketchy right now, and I will be >>> performing more tests >> >> I am puzzled ... and annoyed ;) > > http://i40.tinypic.com/dr6rt.png > 8 minutes later, all the numbers are the same, but cull time increased > by almost 1ms http://i44.tinypic.com/25sos5z.png > 25 minutes later, it's already >10ms ... > > This was with all shaders and other eye candy disabled. Same test with the UFO, cull times also increasing, although the times are smaller but the relative rate is about the same (went from 2.5ms to 3.5ms in about 30 minutes). I have been taking OSG scene graph snapshots, no obvious differences that could cause this (mostly color and time changes). So if the graph is the same, how can cull slow down? Guess I'll have to look at some code and/or ask the OSG folks. -- Csaba/Jester -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] deteriorating cull performance kills fps
On Sun, Dec 18, 2011 at 5:31 PM, Csaba Halász wrote: > On Sun, Dec 4, 2011 at 6:00 PM, Csaba Halász wrote: >> >> I know this information is very sketchy right now, and I will be >> performing more tests > > I am puzzled ... and annoyed ;) http://i40.tinypic.com/dr6rt.png 8 minutes later, all the numbers are the same, but cull time increased by almost 1ms http://i44.tinypic.com/25sos5z.png 25 minutes later, it's already >10ms ... This was with all shaders and other eye candy disabled. Really nobody else seeing this? Any ideas what I could look at to investigate further? -- Csaba/Jester -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] deteriorating cull performance kills fps
On Sun, Dec 4, 2011 at 6:00 PM, Csaba Halász wrote: > > I know this information is very sketchy right now, and I will be > performing more tests Ok, I have done various test flights, the most recent in the ufo with all eye candy disabled, and the problem persists. At the end of an EGCC-EDDF flight (mimicking the flight profile of the concorde), my cull time was up to 22ms limiting fps to about 20. Simply restarting at the same place, cull time was around 4ms with fps in excess of 50. I am puzzled ... and annoyed ;) Also a different issue: I seem to recall there was a golden era when model loading was nicely done in the background, not causing severe stuttering in the display. Nowadays if I look around the scene, FG freezes for seconds at a time. -- Csaba/Jester -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Trying to get more performance out of the 3D clouds!
2011/12/12 Mathias Fröhlich : > > > As an answer to the previous mail, point sprites may help here too. You will > get the bilboard effect for free. > > We have a queriable limit in the maximum supported point size which nobody > guarantees to be really high. But in reality point sprites can get up to > render buffer size for almost any GPU I know. The open source radeon driver > does glClear by drawing a screen sized point sprite... When using the binary fglrx driver there are known problems with point sprites (not sure if anybody ever figured out the real cause) so if we switch to point sprites we should be careful to keep the current method as an alternative for the benefit of fglrx users. -- Csaba/Jester -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flightgear merge request #14 and airportinfo()/navinfo()
On Tue, Dec 13, 2011 at 9:53 AM, Scott wrote: > > Could someone have a look at > > https://gitorious.org/fg/flightgear/merge_requests/14 > > and review. >From a quick glance, you create a hash unnecessarily on line 744: naRef reply = naNewHash(c); It's either overwritten or discarded later. -- Csaba/Jester -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Strange 2.4 Scenery Issue
On Mon, Dec 12, 2011 at 5:50 PM, J. Holden wrote: > > When you said nothing showed up, were you flying over ocean, or an endless > void of nothing at all? Might have been unclear, terrain and the runway do show up, just no objects except for the ones I listed (if they are objects at all). Screenshot: http://i44.tinypic.com/ojjkmq.png -- Csaba/Jester -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Strange 2.4 Scenery Issue
On Mon, Dec 5, 2011 at 6:34 AM, J. Holden wrote: > Just reporting, I've been working on creating some models near PASI. > > When I started up PASI using fgfs --disable-real-weather-fetch --airport=PASI > --aircraft=ufo > > none of the OBJECT_STATIC or OBJECT_SHARED models loaded. OBJECT_SIGN models > DID load, however. Nothing loaded for me no matter if I started locally or flown there from PAOH. The only objects visible were the PAPI/VASI/whatever lights, a windsock and a beacon. Sorry it took me so long to test. -- Csaba/Jester -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Snow line based on METAR
On Tue, Dec 6, 2011 at 9:00 PM, Vivian Meazza wrote: > > I'm not sure that this is correct. Nasal listeners don't mind if a property > is tied or not - this must be true or else weather-utility.nas wouldn't work > to "untie" properties for use by effects. Effects use c++ listeners, and > these do care if a property is tied. Nasal listeners are built on top of c++ listeners. The nasal wrapper even logs a debug message if you attach a listener to a tied property, presumably intended as a warning. weather-utility.nas uses a timer loop triggered each frame to copy the tied properties over. For some obscure reason it also uses a listener coupled to one of the untied property nodes it updates in the loop. It does not use listeners on tied properties. -- Csaba/Jester -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Snow line based on METAR
On Tue, Dec 6, 2011 at 5:15 PM, Gijs de Rooy wrote: > > I wrote a Nasal script, everything works fine, but I stumble accross a > problem with my listener. For > some reason the snow-cover property seems to be tied and therefore it always > reports "nil" to a > listener (AndersG said so, I got no idea what that means). > > Would it be possible to untie the prop? Or is there a better solution? You > can find the script below. You can attach the listener to the metar/valid node which is left untied for this exact purpose. Make sure you trigger for all writes, not just changes (to catch valid->valid updates). -- Csaba/Jester -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Strange 2.4 Scenery Issue
On Mon, Dec 5, 2011 at 6:34 AM, J. Holden wrote: > > The (brand new) Sitka scenery (the chunk south of Juneau) is at > http://www.stattosoftware.com/sitka_scenery.zip Error 404 - FILE NOT FOUND -- Csaba/Jester -- 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] deteriorating cull performance kills fps
Hi people! In recent times, I noticed my FPS goes down the drain during longer flights. I have examined the on-screen OSG stats, and it showed large cull times. No amount of clicking around in the rendering dialog seems to fix this, neither does repositioning to a far away location. However restarting at the same position does. Normally I fly the Concorde exclusively, with shaders, random objects and vegetation plus 3D clouds enabled (basically everything except particles and skydome) so I can't pinpoint the exact cause yet. I have noticed that enabling random vegetation makes the number of vertices skyrocket to 200 million (!) in a short time, but that doesn't seem to impact cull times or FPS. Also the values go back to normal once I disable them. 3D clouds do have an effect on cull times and FPS, but they also seem to return to normal once disabled. At the moment, I am at the end of a test flight with no shaders enabled, just random objects, vegetation and 3D clouds and the problem occurred. Could be related to the high altitude or the long distance as well. I am not too keen on git-bisect given the time to perform a test but I think this issue popped up fairly recently. However it also occurred with shaders disabled, hence I don't think it is related to the recent shader work. I know this information is very sketchy right now, and I will be performing more tests (one of which would be a similar flight with everything disabled and another with the ufo, to rule out the Concorde itself as a possible issue). In the meantime, if anybody else is seeing this or has any ideas, please comment. -- Thanks, Csaba/Jester -- 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
Re: [Flightgear-devel] Terragear now sans plib
On Mon, Nov 7, 2011 at 12:33 PM, Martin Spott wrote: > James Turner wrote: > >> This is fixed now, though I don't really understand how it ever >> worked - rawdem.c wasn't checking a particular return code nicely, >> now it does. > > Thanks a lot, things are looking much better now ! Indeed, valgrind seems to be happy now. -- Csaba/Jester -- 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] Local weather stopped working
On Sun, Oct 30, 2011 at 10:20 PM, Durk Talsma wrote: > > Nasal runtime error in Nasal/local_weather/local_weather.nas:line 1480, no > such symbol 'c'. The offending line is: > > local_weather.cloudassembly.rel_alt = c.alt - c.mean_alt The variable c is indeed not defined anywhere I can see. My *guess* is the line should read: local_weather.cloudAssembly.rel_alt = alt - cloud_mean_altitude; That should make nasal happy, but whether it does what was originally intended, I do not know. -- Csaba/Jester -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] segfaults/memory corruption back
I can't provide specifics yet, but I have a feeling our old friends, random segfaults and "glibc detected" memory corruption, are back with a vengeance. Anybody else noticed it? -- Csaba/Jester -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] SGMath headers
While investigating a reported compilation error, I had a look in the SGMath headers. I noticed some of them don't properly include their dependencies (for example, SGMisc is missing SGCMath, SGGeodesy is missing SGVec3 and SGGeod, etc.). I am wondering if they are supposed to be available for standalone use, or only via the SGMath.hxx header, which does at least try to include the dependencies (even though it doesn't get the order right.) The current issue is with SGMisc as used in src/Environment/presets.cxx, because that doesn't happen to include cmath beforehand. Would be easy to fix there, but that's not the right way so I am not doing it. -- Csaba/Jester -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object scope help
On Tue, Oct 11, 2011 at 11:31 PM, Robbo wrote:
>
> The classes are instantiated within instrument_manager:
>
> } else if ( name == "taradar" ) {
> set_subsystem( id, new TaRadar( node ), 1 );
Notice that the subsystem will be registered using the "id" not the
"name". So make sure you are using the correct value when retrieving
it, below:
> TaRadar* _taradar_node = (TaRadar*) globals->get_subsystem("taradar");
--
Csaba/Jester
--
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. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Query about groundradar Instrument module
On Thu, Sep 29, 2011 at 10:32 PM, Robbo wrote: > Hi, > > Essentially, there is a 'texture' declared as follows: > static const char* default_texture_name = > "Aircraft/Instruments/Textures/od_groundradar.rgb"; > > FGTextureManager::addTexture(texture_name, getTexture()); > > Now all is good at this point until I go and look for this file, which i > expected to find in data/Aircraft/Instruments/Textures/, however, this file > does not appear there, nor does it appear anywhere else on my filesystem > either. > > I thought, well maybe the code is not actually using this texture, since its > a 'default_texture', however, when i change the name to point to something > else which also does not exist, then, the once black background becomes > white! > > So I am assuming that this file MUST be somewhere, but I have no idea where > it is, can anyone assist me with this? That is the name of the generated dynamic texture, the "od_" prefix is supposed to signal this for "owner drawn", see od_gauge.cxx/hxx. The call you found actually registers it with the texture manager so that other components (notably models) can refer to it by that name. -- Csaba/Jester -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] database or php error in the wiki
On Sun, Sep 25, 2011 at 2:52 PM, Erik Streb del Toro wrote: > > I just registered for the flightgear wiki. When I try to access “my > preferences” via http://wiki.flightgear.org/Special:Preferences I get > the following error: > > --- > Internal error > > Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php > to show detailed debugging information. > --- > > I just tried it with a new account and again the same issue. Same here. -- Csaba/Jester -- 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] FG hangs on "loading scenery" when using many objects
On Wed, Sep 21, 2011 at 11:07 PM, Thomas Albrecht wrote:
>
> On machine (much slower than yours: Pentium 4 2.4 GHz, 1.5GB DDR), FG hangs
> when using ~2300 objects.
Here, with AMD 605e 2.3GHz, it hangs at around 5800 objects, with the
CPU behaviour you described. Going slightly higher, from around 6000,
FG starts to burn CPU again, but nevertheless won't get any result.
Looking into the problem, seems the scenery is loaded eventually, but
the fdm is not initialized so this check never passes:
if (globals->get_tile_mgr()->isSceneryLoaded()
&& fgGetBool("sim/fdm-initialized")) {
Now, the FDM init code has this:
if (globals->get_scenery()->scenery_available(geod, range)) {
SG_LOG(SG_FLIGHT, SG_INFO, "Scenery loaded, will init FDM");
That in turn ends up at:
simgear::CheckSceneryVisitor csnv(getPagerSingleton(), toOsg(p),
range_m, framestamp);
// currently the PagedLODs will not be loaded by the DatabasePager
// while the splashscreen is there, so CheckSceneryVisitor force-loads
// missing objects in the main thread
get_scene_graph()->accept(csnv);
if(!csnv.isLoaded())
Finally we arrive at:
void SGPagedLOD::forceLoad(osgDB::DatabasePager *dbp, FrameStamp* framestamp,
NodePath& path)
{
//SG_LOG(SG_GENERAL, SG_ALERT, "SGPagedLOD::forceLoad(" <<
//getFileName(getNumChildren()) << ")");
And now the crazy part! If I uncomment this logging, everything
suddenly works, even with 20k objects:
http://i53.tinypic.com/wwn12f.png
Sounds like some timing/threading issue to me.
--
Csaba/Jester
--
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. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Repeatable random seeds
On Fri, Sep 16, 2011 at 10:35 AM, Andreas Gaeb wrote: > > However, the sg_srandom_time_10() function also looks appealing. That > would give the same random seed for all processes started within the > same 10 minute interval, yet also vary every 10 minutes even with the > same METAR. Maybe even METAR updates are possible if an update re-seeds > from that function. Ideally, we want MP to be synchronized too, and also if you restart FG on one of the machines it should pick up the same random stream again. -- Csaba/Jester -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issues with Git Pull on fgdata
On Fri, Sep 16, 2011 at 12:06 AM, Jason Cox wrote: > Hi all, > I am need of updating my fg data but am finding that the git pull fails > after a while stating that the remote end has disconnected my session. > As this an extremely large download that cannot be interrupted I am just > wasting large amounts of broadband allowance trying to do this. > > Is there a way of downloading just the head in a tar ball from a web > site? You can use a recent git bundle that is a resumable download, and bring that up to date with a comparatively small pull afterwards. See http://wiki.flightgear.org/FlightGear_and_Git#fgdata.bundle Also, the mapserver git mirror usually has no problems with the large data. -- Csaba/Jester -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NASAL permissions
On Wed, Sep 14, 2011 at 12:37 AM, Adam Dershowitz, Ph.D., P.E.
wrote:
>
> I have a script that is giving me permission errors when it runs. The scrip
> is in data/Nasal. It contains this line:
> var file=io.open("data/latlong.csv",mode="r");
Try this:
var file=io.open(getprop("/sim/fg-root") ~ "/latlong.csv",mode="r");
--
Csaba/Jester
--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
Learn about the latest advances in developing for the
BlackBerry® mobile platform with sessions, labs & more.
See new tools and technologies. Register for BlackBerry® DevCon today!
http://p.sf.net/sfu/rim-devcon-copy1
___
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 Sun, Sep 4, 2011 at 8:56 PM, ThorstenB wrote: > > I'm currently looking into an overhaul of the replay system. My idea would have been to drop the classic replay functionality, and instead use the MP subsystem to record both incoming and outgoing data (some extra properties would still need to be recorded, though, such as weather stuff). This would allow replay of MP happenings properly. Eventually we could also have offline rendering with custom camera paths and such goodies. Also, while replaying I would leave the FDM and all the systems running, effectively simulating the pilot viewing a recording while still flying. This is to avoid disturbing other pilots on MP. Simpler code would be to only allow replay while stationary, in which case all aircraft systems could be paused (this would be easier to code) or at the very least forcibly freeze MP state. Of course in my opinion the best option would be to put replay functionality into some external application, such as fgviewer, but I already hear the people complaining :) -- Cheers, Csaba/Jester -- 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] Keyboard Map
On Wed, Aug 10, 2011 at 8:42 PM, Rob wrote: > Hi all, figured out how to change/setup/remove key commands for aircraft > in the -set.xml. My question is what character map are you using to come > up with the Key number? See fgdata/Docs/keyboard/map.pdf and also the first screenful of fgdata/keyboard.xml (especially the "uncomment this line to get keycode reports printed to the terminal window") -- Csaba/Jester -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scripted compile from source... results in run_fgrun buttons greyed out, or fgfs cannot open shared object file
On Thu, Aug 4, 2011 at 5:29 PM, marthter wrote: > > I noticed that there were in fact 7.2 GB in the fgdata/.git folder (and no > other folders present within fgdata at all), so it seemed all the > downloading had been done, just none of the git magic to actually show any > files. Ok, then try the git magic: git checkout master If that doesn't work, try: git branch -vr, check if that shows maybe origin/master. If so, do git checkout -b master -t origin/master. -- Csaba/Jester -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scripted compile from source... results in run_fgrun buttons greyed out, or fgfs cannot open shared object file
On Thu, Aug 4, 2011 at 12:22 AM, marthter wrote: > > > I also have separately installed FlightGear via the package manager, so I > tried pointing FG_AIRCRAFT at what appears to be the Aircraft directory, > > Also when I guessed at what to put for the terrasync exe spot, which I found > in ~/flightsim/install/fgfs/bin/terrasync, the Next button is still greyed > out. No idea about fgrun, but these two settings are optional. FG knows to look for the default aircraft in FG_ROOT/Aircraft, you only need to set this if you have an additional custom location. Terrasync is not required. > I also tried this without using run_fgrun, but just using fgrun: > > $ cd ~/flightsim/install/fgrun/bin > $ ./fgrun > ./fgrun: error while loading shared libraries: libosgParticle.so.66: cannot > open shared object file: No such file or directory > $ > > I also tried without using > $ cd ~/flightsim/install/fgfs/bin > $ ./fgfs > ./fgfs: error while loading shared libraries: libosgFX.so.66: cannot open > shared object file: No such file or directory These are normal, the wrapper scripts contain code to set LD_LIBRARY_PATH such that the system can locate the required dependencies. You can of course do that manually too. Note that you'll have to supply fgfs with the path to the data directory using the --fg-root option. Verify that the script downloaded the data for you. Should be easy to notice, it is a >3GB download :) Looks similar to what you have found in the installed package (but the two versions are not compatible). I suspect your GIT error message might indicate failed data download. For the already filled out paths in the fgrun page, verify that those actually exist and are readable. -- Csaba/Jester -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error --> Error opening serial device "COM27" The system cannot find the file specified.
On Wed, Aug 3, 2011 at 8:53 PM, Gene Buckle wrote: >> > COM27 is also a suspicously(sp) high port#. That seems to be quite normal for usb adapters. However you are right that this is the cause of the problem. Quote from msdn: To specify a COM port number greater than 9, use the following syntax: "\\.\COM10". This syntax works for all port numbers and hardware that allows COM port numbers to be specified. (source: http://msdn.microsoft.com/en-us/library/aa363858%28v=vs.85%29.aspx) -- Csaba/Jester -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] startup crash in SimGear (with patch?)
On Mon, Aug 1, 2011 at 2:24 PM, James Turner wrote: > > Can anyone think of a reason particles are fine for some (many?) people > without this patch? Of course the patch should be applied, I'm just wondering > what would affect the ref-counting logic to hide the problem in some machines > / environments. Deleted memory is not immediately overwritten, so maybe for lucky people the contents stay there longer. There are ways to force freed memory to be overwritten by some marker (such as 0xdf using dmalloc), could be worth a try. -- Csaba/Jester -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] startup crash in SimGear (with patch?)
On Mon, Aug 1, 2011 at 5:41 AM, Ove Kåven wrote: > > If there are no other references, the prop_root is automatically > destroyed when sgLoad3DModel_internal returns, causing the memory to be > freed. So, later on, when OSG wants to do something with these > particles, the freed memory is referenced and causes a crash. Indeed, I have been unable to run FG with particles enabled since a long time due to random crashes in the particle code. Call stack frequently included functions your description mentions, so I hope this patch will fix that issue. Thank you. -- Csaba/Jester -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Current Weather System...
On Thu, Jul 14, 2011 at 10:36 PM, James Turner wrote: > > On 14 Jul 2011, at 12:46, thorsten.i.r...@jyu.fi wrote: > >> Nasal has a garbage collection problem. One solution to it is - we avoid >> Nasal code wherever possible and try to hard-code everything. But Nasal >> crops up on a lot of places - complex aircraft such as the Concorde come >> to my mind, interactive AI models, lots of really nifty and useful >> applications... - so instead of fixing things in a lot of places, one >> could also think about it the other way and fix just one thing, i.e. the >> garbage collection such that it doesn't hit a single frame. > > Indeed, and I've looked into this - it's a tough problem, but not an > impossible one - and well contained - the current Nasal GC is a single source > file. As you point out, the amount of scripted code is going to continue > increase irrespective of local weather, so we need to bite the bullet sooner > or later and fix the GC to be incremental. > > Fortunately, garbage collection is pretty well researched - the trick is > finding an incremental algorithm that's 'simple enough' Note, Anders has created a patch that puts GC on its own thread a while ago. Admittedly that's not incremental, but still nice. -- Csaba/Jester -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG 2.4 consistency
On Wed, Jul 13, 2011 at 3:24 PM, grth_team wrote: > > We have learnt we must not contribute to GPL update within FG, since > the FG team answers does not convince us to contribute, we do not want > to waste time. > > To please to the users, our model will be ever checked against an FG > stable version. > We will start that rule with FG 2.4, offering our models within our > pages, but, under an other license. I fail to see how your problem has anything to do with licensing. -- Csaba/Jester -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft selection for 2.4.0
On Mon, Jul 4, 2011 at 11:50 AM, wrote: > > The AP has some trouble following a VOR radial or intercepting a > glideslope, but then I don't really know any airliner (with the exception > of the Concorde) which doesn't have any oddity in the AP. Rest assured, the Concorde has its share of oddities :) See the "known problems" part in the ReadmeConcorde-jbsim.txt. -- Csaba/Jester -- 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-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Objects not loading after recent upgrade
On Sun, Jul 3, 2011 at 1:52 AM, Chris Wilkinson wrote: > Hi Martin, > I re-read the messages on starting and I see... > > loadxml: reading '' denied (unauthorized access) > > Seems odd. I ran chmod to ensure no read permissions are unset, and chown > and chgrp to ensure all files are set to my user 'chris' and group 'users'. > Still get the same message. Is this perhaps a problem with the compile I've > done? That error is coming from nasal, based on the IORules settings. It isn't a file system permission problem and probably has nothing to do with your compilation. The empty file name is highly suspicious, somebody is invoking loadxml wrong. Try to find out who :) -- Csaba/Jester -- 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-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard weirdness: shift modifier stays on
On Wed, Jun 29, 2011 at 4:44 PM, Sylvain Mazet wrote: > OK, > > I tracked this, I am answering myself for the record. > > It seems on left-shift-key release, Xorg sends a release event with a wrong > keysym (XK_ISO_Prev_Group instead of XK_Shift_L). > > Same thing for right shift key. On release, the X11 keysym is > XK_ISO_Next_Group instead of XK_Shift_R. > > Maybe this concerns OSG people? Xorg people? Sounds like Xorg ... look in your keyboard configuration files. For reference, here is my xev output: KeyPress event, serial 29, synthetic NO, window 0x281, root 0x117, subw 0x0, time 775114491, (46,147), root:(981,280), state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 29, synthetic NO, window 0x281, root 0x117, subw 0x0, time 775114555, (46,147), root:(981,280), state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False -- Csaba/Jester -- 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-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Fri, Jun 24, 2011 at 1:13 PM, Vivian Meazza wrote: > > Seriously, Git has never been right for the data. We were promised a fix, > which has never materialized. SVN can be no worse, and it might be better. > Terrasync indicates that it might well be better, and might give us the > ability to pull aircraft down for MP on the fly. Ok, here is my usual negative comment (only by request :P) Could we please forget SVN forever? Thank you. Applies to scenery too, although I have been told its use was introduced to get free hosting from google and not for technical merit. Using SVN so you can download stuff on the fly is ridiculous, that's not the task of a revision control system (and built scenery probably doesn't need a revision control anyway). For all development tasks SVN is clearly worse than GIT (branches, local changes, merge requests, client side history, backups, etc.), and it isn't particularly good at the download part either. Also, an eventual automated aircraft download system should allow for 3rd party hangars too (would be the most important benefit, if you ask me), and not force SVN upon everybody. We should keep it simple, and probably just use regular snapshots from the revision control system made available via http. To summarize: if we want to split fgdata or allow automatic aircraft (model) downloads, that's fine with me, but I don't think SVN is the right tool for the task(s). -- Csaba/Jester -- 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. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download / built-in
On Wed, Jun 15, 2011 at 10:57 PM, Martin Spott wrote: > Csaba Halász wrote: > >> Finally, there could be other programs that need scenery data, would >> you embed terrasync in each one? I view this as bad design. > > By having a closer look at Thorsten's patches you'd realize that his > primary work was to turn the standalone program with hard-coded host- > and pathnames into a neatly configurable library. The interface > between this lib and FlightGear is pretty slim, it doesn't add much > overhead and you're free not to use it. I am not arguing to remove this, I am just saying I don't like the general tendency. Obviously removing stuff that has already been coded (and is at least marginally useful) is an entirely different thing than deciding to not do something in advance. I must have missed the mail thread where this modification was proposed and discussed. > BTW, while I'm very much in favour of having FlightGear's various > subsystems split into distinct parts, I think the "bad design" claim > coming from you is pretty weak. Where was your voice when the Local > Weather subsystem was added ? There could be other programs that need > the same local weather, let's say multiple viewer instances on the same > FlightGear scenario. That was a new system that happened to be born in FG, not an already well established standalone program that we suddenly integrated. In any case, missing one opportunity to spot trouble doesn't mean I have to give up my voice forever (and also doesn't invalidate any arguments). > Adding another 'wrapper' around libsgtsync, let's say a configurable > HLA interface, and removing the current one from FlightGear is > extremely cheap compared to making local weather multi-viewer > compatible. Just a random example, think about it Implementation difficulties don't really concern theoretical design, but of course certain tradeoffs might have to be made in practice. -- Csaba/Jester -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download / built-in
On Wed, Jun 15, 2011 at 7:35 PM, Martin Spott wrote: > "Vivian Meazza" wrote: > >> [...] And I can't see any real advantage over Fred's implementation in >> FGRun, which I have used for years. > > Some people _do_ see a real advantage. > >> This is more or less consistent with Gene's, Csaba's and Ron's view - I'm >> happy to set this all up, and more, in a separate GUI. > > "This" is not consistent with Gene's, Csaba's and Ron's view. If you > read carefully, then you'll realize that these three guys have > primarily expressed their opinion on wether to have the GUI inside the > visual system or not. It is pretty consistent with mine, actually. For example, if you have 2 separate scenery "consumers" it would make sense if they both sent requests to the same terrasync instance. If both included their own terrasync copy, who knows what confusion might result (double download, svn lock, etc.). Another scenario could be if the scenery data resided on a separate machine - it would make sense to run a terrasync daemon there and not embedded in FG. My setup is an example for both cases, because I have my scenery data on an NFS share that my laptop and my desktop use. Finally, there could be other programs that need scenery data, would you embed terrasync in each one? I view this as bad design. -- Csaba/Jester -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download / built-in terrasync
On Mon, Jun 13, 2011 at 9:50 PM, ThorstenB wrote: > > the final GUI bits for a new feature are now in fgdata - the last > feature addition for the 2.4 release from my part... You can > download/update scenery directly from FlightGear now (main menu: > Environment => Scenery). Credit for the idea goes to James - bugs are > mine ;-). For the record, I don't think we are going in the right direction with this. I personally think more modules should be split out rather than integrated. For example, all the GUI stuff should be thrown out and left to a launcher/control console application. We could then get rid of plib and avoid the "what gui toolkit to use" controversy (at least for the core FG). FDM and visualization should also be split, obviously with multiple instances allowed of either. -- Csaba/Jester -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots with OSG multi-threading
On Sat, May 28, 2011 at 11:33 PM, ThorstenB wrote: > Hi, > another heads up: I've pushed a patch fixing screen shot issues in OSG > multi-threading modes (see in preferences.xml). > Please test this on your machines, with your favourite OSG threading > mode. As usual, report any issues - here or there: > http://code.google.com/p/flightgear-bugs/issues/detail?id=127 This commit is buggy too :-> Okay, I'll be nice and provide a hint: It is not safe to call removeTask from the timer event itself. -- Csaba/Jester -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Testing OSG-trunk / bug issue #268
On Wed, May 18, 2011 at 11:04 PM, ThorstenB wrote: > On 18.05.2011 22:45, Csaba Halász wrote: >> Turns out 12303 is the cause for the constant sunshine ;) > Great! Excellent you've found it! > >> Specifically, the GLSL version parsing has been broken: Fixed in OSG rev. 12454 -- Csaba/Jester -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Writing output to physical nasal file - How To
On Thu, May 26, 2011 at 3:26 PM, xsaint wrote: > Thanks for the replies so far > > My apologies, yes i tried to change the entries earlier on the iorules > file, still i had the same error...and even when i tried saying to FG > root or data, same error. > I will like to save the file to FGData folder. Judging by the error message, you forgot to prepend the correct path to your filename. -- Csaba/Jester -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Writing output to physical nasal file - How To
On Thu, May 26, 2011 at 2:53 PM, xsaint wrote: > > I am trying to capture some values from FG property tree at 5 minutes > interval and write these values to a file called , "capture.log" > With my limited knowledge in nasal, i am getting "io.open(): opening > file 'cna.log' denied (unauthorized access)" Nasal file permissions are controlled by the $FG_ROOT/Nasal/IORules file. Edit it based on the comments at the top, or use a file that is allowed by default, such as $FG_HOME/*.log -- Csaba/Jester -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Testing OSG-trunk / bug issue #268
On Wed, May 18, 2011 at 8:19 PM, ThorstenB wrote: > > Thanks Csaba, that's already close! I looked at the commit logs but > didn't find any obvious culprit. A good next test would be r12312 - ... which is broken. Turns out 12303 is the cause for the constant sunshine ;) Specifically, the GLSL version parsing has been broken: Original code: _glslLanguageVersion = asciiToFloat( langVerStr ); New code: _glslLanguageVersion = ( asciiToFloat( glslvs.substr( glslvs.find( "GLSL "+5 ) ).c_str() ) ); The version string for me here is simply "3.30" (using fglrx 11.4), so the old code works but the new one doesn't. Incidentally, the GL version parsing doesn't work either, because version string is "3.3.10666 Compatibility Profile Context" and the code (both the old and the new) expect a decimal number before the space. I can't really believe this is the best way to get version numbers from opengl. -- Csaba/Jester -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Testing OSG-trunk / bug issue #268
On Wed, May 18, 2011 at 8:45 AM, ThorstenB wrote: > working/non-working OSG revision in between 11900 and 12419, you're > welcome to let us know. Also, maybe someone has an extremely powerful > machine and could help with testing different OSG revisions. My machine is not extremely powerful, but 12300 works while 12330 doesn't. -- Csaba/Jester -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Testing OSG-trunk / bug issue #268
On Wed, May 18, 2011 at 12:36 AM, Csaba Halász wrote: > On Wed, May 18, 2011 at 12:25 AM, ThorstenB wrote: >> >> Also: it seems 3D clouds are broken with current OSG-trunk. Works well >> for me with older OSG versions. Can anyone else confirm the issue? > > I don't get any 3D clouds at the moment, but I assumed that was > because I also upgraded graphics driver (fglrx 11.4) at the same time. Downgraded to svn rev 11900, got 3D clouds back. Note, I am not saying the breakage occurred there, I just randomly picked that as a testing point. -- Csaba/Jester -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Testing OSG-trunk / bug issue #268
On Wed, May 18, 2011 at 12:25 AM, ThorstenB wrote: > > Also: it seems 3D clouds are broken with current OSG-trunk. Works well > for me with older OSG versions. Can anyone else confirm the issue? I don't get any 3D clouds at the moment, but I assumed that was because I also upgraded graphics driver (fglrx 11.4) at the same time. -- Csaba/Jester -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: fgdata merge request 76:Improvedairport Textures
On Wed, May 11, 2011 at 11:24 PM, Heiko Schulz wrote: >> >> Anybody got a screenshot with stopways? > > Yep: > www.hoerbird.net/fgfs-screen-251.jpg Thanks! Apparently I have to use the scenery from fgdata and not terrasync. With that, I have stopway with both the old and the new textures. -- Csaba/Jester -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: fgdata merge request 76:Improvedairport Textures
On Wed, May 11, 2011 at 6:38 PM, Vivian Meazza wrote: > Christian Schmitt wrote >> >> The stopways still work for me here, so there is maybe something wrong in >> your fgdata? > > I have absolutely up-to-date data and source from Git here - still no > stopways. Is your data up-to-date? But I suspect that the error is local, > since there are no other reports of this problem. For the record, I don't think I have ever seen any stopways. I have now checked with fgdata from before the new textures were committed and the current head - no stopways with either. Anybody got a screenshot with stopways? -- Cheers, Csaba/Jester -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TerraGear - removing the 'terror' ;=))
On Tue, May 3, 2011 at 7:33 PM, Geoff McLane wrote: > > But even after that install, the command - > $ apt-file search libodbcinst.so > still shows 'nothing' ;=(( "apt-file search" searches the package lists, not the installed files. If it shows nothing, that means you have probably forgotten to run "apt-file update" recently. It lists the packages containing a given file even if the package is not installed (would be quite useless otherwise). To search the installed files (ie. list which package, if any, a given file on your system came from), you want "dpkg -S". > But next got stuck on -lmfhdf... tried libhdf5-mpich-dev, > but that then un-install the above 'serial'... so do > not think it is that... > > Any idea what to install for this? Once you fix your apt-file it should show you that: $ apt-file search libmfhdf.so libhdf4-0: /usr/lib/libmfhdf.so.0 libhdf4-0: /usr/lib/libmfhdf.so.0.0.0 libhdf4-dev: /usr/lib/libmfhdf.so So, install libhdf4-dev > _AND_ I am sure I may need help on other names that > look quite unfamiliar like - > > -ldf -logdi -lnetcdf -lpq -ldl -lgssapi_krb5 You can use apt-file to find the packages for these as well. - df is included in libhd4-dev that you installed above. - ogdi is in libogdi3.2-dev - netcdf is in libnetcdf-dev - pq is in libpq-dev - dl is in libc6-dev (probably already installed) - gssapi_krb5 is in libkrb5-dev Also note, installing libgdal1-dev would have pulled in most of these automatically. -- Csaba/Jester -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TerraGear - removing the 'terror' ;=))
On Mon, May 2, 2011 at 7:41 PM, Geoff McLane wrote: > > BUT ran out of PUFF on the next -lodbcinst ;=)) > > There seems NO libodbcinst* in my system, although > there is a - > /usr/bin/odbcinst > which, when run, just outputs - > unixODBC 2.2.11 > but how to get a 'library'??? $ apt-file search libodbcinst.so ia32-libs: /usr/lib32/libodbcinst.so.1 ia32-libs: /usr/lib32/libodbcinst.so.1.0.0 ia32-libs-dev: /usr/lib32/libodbcinst.so odbcinst1debian2: /usr/lib/libodbcinst.so.1 odbcinst1debian2: /usr/lib/libodbcinst.so.1.0.0 sun-java6-bin: /usr/lib/jvm/java-6-sun-1.6.0.24/jre/lib/amd64/libodbcinst.so unixodbc-dev: /usr/lib/libodbcinst.so The last is the one to install (it will pull in the dependencies as needed). -- Csaba/Jester -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear compile error
On Thu, Apr 28, 2011 at 6:24 PM, Geoff McLane wrote: > On Thu, 2011-04-28 at 13:40 +0200, Csaba Halász wrote: > [] >> NULL has never been officially defined in any C++ header that I know. >> So code that relies on that is broken. > [] > > It is interesting you say that... do you have a reference? > Always interested to learn, know more ;=)) Erm, standards won't list things NOT defined, sorry :) > Does that not indicate NULL is defined in , or > in another header included by it, or do you not consider > this a C++ header? Or something... Indeed, stdio.h is not a c++ header. In C++ code, you can get NULL defined if you include or (and probably others, for which the C standard says it defines NULL). -- Csaba/Jester -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear compile error
On Thu, Apr 28, 2011 at 12:46 AM, Arnt Karlsen wrote: > On Wed, 27 Apr 2011 15:13:21 +0200, Geoff wrote in message > <1303910001.6472.18.camel@DELL02>: > > ..if you bother to try that approach with my post to the list, > you may see I addressed the list with this implied question: > In file included from component.cxx:4:0: > component.hxx:191:28: error: reference ‘_table_manager’ cannot be > declared ‘mutable’ [-fpermissive] > > ..which I don't yet know how to fix. After a quick glance at the code I don't see why the mutable is needed there. Just remove that keyword. You could of course also use the -fpermissive switch as indicated by the error message. While that wouldn't actually fix the problem but it would get you a successful build. >> You know this will get quite BORING if you keep telling >> us about gcc 4.6 problems, if it is in fact a gcc >> problem... It isn't a gcc problem. It should not have worked *EVER*. It's just that gcc is being updated to detect more and more illegal things. >> Is it that a definition of a NULL has been removed from >> some standard headers, or is it really just gcc/g++ being >> picky? NULL has never been officially defined in any C++ header that I know. So code that relies on that is broken. -- Csaba/Jester -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
On Sat, Apr 23, 2011 at 5:00 PM, Christian Schmitt wrote: > Csaba Halász wrote: > >> Hm, ok, that doesn't seem to be SSE related, it's just your everyday >> NULL pointer. >> Have to check source code to see how that can happen. > > > Did you look into this already? Yes. > Would be a good start to fix this (if the problem is not IN the gpc lib). Don't know where the problem is. Unfortunately, the gpc code in question isn't trivial. In the invocation "merge_left(cf, edge->outp[BELOW], out_poly);" the second parameter seems to be NULL, but how that is calculated isn't obvious. -- Csaba/Jester -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Splitting fgdata
On Wed, Apr 20, 2011 at 11:05 PM, Arnt Karlsen wrote: > > ..should say: wget -c \ > http://flightgear.mxchange.org/pub/fgfs/fgdata.bundle > so the download can be resumed if it stalls or somesuch, > rather than try wget the whole bundle into fgdata.bundle.1, > fgdata.bundle.2 because etc those widely documented writings > aren't as widely read. ;o) man wget: Note that you don't need to specify this option if you just want the current invocation of Wget to retry downloading a file should the connection be lost midway through. This is the default behavior. `-c' only affects resumption of downloads started _prior_ to this invocation of Wget, and whose local files are still sitting around. PS: installed nouveau, not much luck with it yet -- Cheers, Csaba/Jester -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
On Mon, Apr 18, 2011 at 1:38 PM, Christian Schmitt wrote: > Csaba Halász wrote: > >> Info registers, and something like x/10i $eip (or $rip on 64 bit) >> > > Here you go (still on Atom), Phenom this evening. > > (gdb) info registers > eax 0x0 0 > > (gdb) x/10i $eip > => 0xb7fb8fdd : mov 0x14(%eax),%eax Hm, ok, that doesn't seem to be SSE related, it's just your everyday NULL pointer. Have to check source code to see how that can happen. -- Csaba/Jester -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
On Mon, Apr 18, 2011 at 12:16 PM, Christian Schmitt wrote: > > I can get that for you, if you want. But what do you need? > info registers? The whole coredump file? Info registers, and something like x/10i $eip (or $rip on 64 bit) -- Csaba/Jester -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
On Sun, Apr 17, 2011 at 6:37 PM, Martin Spott wrote: > Christian Schmitt wrote: >> Martin Spott wrote: > >> The O2 flag was set for all tries but it's not the problem here. The problem >> are certain -march options. "-march=core2 -mfpmath=sse" for the Atom showed >> the error. Settung it to a more conservative "-march=prescott" makes it >> work. In this case it was a clear overoptimization. > > Well, to be more precise, it's been optimization for an incompatible > platfom ;-) > The Core2 has a slightly different instruction set from the Pentium > III, thus, if I were you, I'd let the 'native' compiler choose the > right platform optimization for you - as long as you don't compile > cross-platform. It is certainly good advice to optimize for the correct processor, but using unsupported instructions typically result in a SIGILL not a SIGSEGV. It would help to see the actual disassembly around the fault and machine register contents. It smells like alignment problem. -- Csaba/Jester -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear GIT version 64bit problem
On Fri, Apr 15, 2011 at 1:11 AM, Ozgur wrote: > Hi all, > > I install Debian squeeze 64 bit. > > /usr/bin/ld: i386 architecture of input file > `/usr/local/games/FlightGear/lib/libsgbvh.a(BVHStaticNode.o)' is > incompatible with i386:x86-64 output You somehow managed to build a 32 bit simgear. Make sure you build a 64 bit simgear for a 64 bit flightgear. -- Csaba/Jester -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG caching
On Wed, Apr 13, 2011 at 9:16 PM, ThorstenB wrote: > * or it's all our fault, our leak alone - more or less unrelated to caching. > > I think the latter is (still) the case. I already posted some weeks ago > that I was seeing loads of leaked objects. I managed to fix a few things > at the time > > I never ran FG for 6 hours with clouds & MP enabled though. But are we > sure that the OSG cache itself really made a major difference now? Yes, pretty sure. I fly FG during the monthly TGA events, and it was never even half as bad as this time. Except for the one massive leak you fixed, but luckily I didn't try to run that version during an event :) -- Csaba/Jester -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG caching
On Wed, Apr 13, 2011 at 1:29 PM, wrote: > > I've got a stupid question - maybe someone who knows these things can > educate me. > > If I do not use texture caching, textures are loaded from harddisk every > time I need them, for each and every model. > > If I do use texture caching but my memory runs over, swapping takes place. > Sometimes I may get lucky and the texture I need is currently in memory, > sometimes it is on harddisk and needs to be loaded. > > Naively, it seems to me the second case is still faster than the first, > because I always save at least some harddisk operations. I haven't flown > for 6 hours straight with CACHE_ALL, but for two hours something, and it > was still way faster than with CACHE_NONE. Depending on the format of the textures on disk and in memory, reading and converting a possibly smaller texture from the original file may be faster than reading back the already converted texture from swap (if it is not in memory at the given time). Additionally, I was almost at the limit of available swap space, I had to add a temporary swap file for fear of running out of virtual memory and thus getting a crash. (Would have sucked after 6 hours of flight). As I said, I was up to 7GB but I use a 64 bit system. People with 32 bit machines would run into trouble much earlier, typically at 2 or 3GB already. -- Csaba/Jester -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ..now, running it...
On Sun, Apr 10, 2011 at 10:23 PM, Arnt Karlsen wrote: > Hi, > > ..now, running it... > loading scenario 'nimitz_demo' > ALSA lib pcm.c:2190:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear > ALSA lib pcm.c:2190:(snd_pcm_open_noupdate) Unknown PCM > cards.pcm.center_lfe ALSA lib pcm.c:2190:(snd_pcm_open_noupdate) > Unknown PCM cards.pcm.side ALSA lib pcm_dmix.c:1018:(snd_pcm_dmix_open) > unable to open slave ALSA lib pcm_dmix.c:957:(snd_pcm_dmix_open) The > dmix plugin supports only playback stream ALSA lib > pcm_dmix.c:1018:(snd_pcm_dmix_open) unable to open slave Cannot connect > to server socket err = No such file or directory Cannot connect to > server socket jack server is not running or cannot be started It tries to fall back to jack after it fails to use ALSA, which seems to be messed up. Check whether alsa works with aplay -D plug:dmix foo.wav, then try creating an ~/.alsoftrc with explicit ALSA only (or /dev/null for no-sound testing). > ..and why does it try to load the Nimitz demo??? Because it is enabled in the default in preferences.xml. -- Csaba/Jester -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ..does fgcom builds depend on a successful fgfs build?
On Sun, Apr 10, 2011 at 11:15 PM, Arnt Karlsen wrote: > Hi, > > ..first build failed on missing separators???, the next on: > fgcom.cpp: In function ‘int main(int, char**)’: > fgcom.cpp:374:53: error: ‘SPECIAL_FREQUENCIES_FILE’ was not declared in > this scope > fgcom.cpp:378:31: error: ‘DEFAULT_POSITIONS_FILE’ was not declared in > this scope As far as I have heard, the script is not updated for the current svn version of fgcom and it mangles the makefile that has those macros defined improperly, thereby removing them. To answer your question, though: FGCom does depend on simgear but not on FG itself. -- Csaba/Jester -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ..simgear(?) link error, undefined references to SGPagedLOD
On Sun, Apr 10, 2011 at 12:24 PM, Arnt Karlsen wrote: > Hi, > > ..simgear(?) link error output, compile log link below: > in function vtable for > simgear::SGPagedLOD:SGPagedLOD.cxx(.rodata._ZTVN7simgear10SGPagedLODE+0x110): > error: undefined reference to > 'osg::PagedLOD::removeExpiredChildren(double, int, > std::vector, > std::allocator > >&)' This usually happens if you have multiple versions of OSG installed and the build process happens to find headers for one version, while using the libraries of another version for linking. The general advice is, don't ever have two versions of OSG installed at the same time, no matter what prefix. -- Csaba/Jester -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ..scripted builds fails to build OSG and FG, was: ..tante Ju is nude...
On Sun, Apr 10, 2011 at 2:52 AM, Arnt Karlsen wrote: > > ..was my last successful OSG-build, OSG-2.9.9 and OSG-2.9.11 > now also fails to build with c++-4.5.2-8, I'm using: > http://www.gitorious.org/fg/fgmeta/blobs/raw/master/download_and_compile.sh > (and my own "system-OSG" version of it) as adviced in: > http://wiki.flightgear.org/index.php?title=Scripted_Compilation_on_Linux_Debian/Ubuntu > >> > and >> > compilation_log.2011-04-06+04:33:17 with c++-4.6.0-2. > > ..both plib and SimGear builds ok on c++-4.6.0-2 and my last > OSG, and on system OSG (2.9.11-1), but fgfs build fails with: > make[3]: Entering directory `/home/arnt/FG-git/fgfs/flightgear/src/FDM' > g++ -DHAVE_CONFIG_H -I. -I../../src/Include -I../.. -I../../src > -I../../src/FDM/JSBSim -I/home/arnt/FG-git/install/simgear/include > -I/home/arnt/FG-git/install/plib/include -I/usr/local/include -g -O2 > -Wall -I/home/arnt/FG-git/install/simgear -D_REENTRANT -MT > flightProperties.o -MD -MP -MF .deps/flightProperties.Tpo -c -o > flightProperties.o flightProperties.cxx > In file included from > flightProperties.cxx:23:0: ../../src/FDM/flightProperties.hxx:48:44: > error: ‘NULL’ was not declared in this scope > > ..line 47-49 in ../../src/FDM/flightProperties.hxx: > public: > FlightProperties(SGPropertyNode* aRoot = NULL); > ~FlightProperties(); Indeed, NULL is a C thing, in C++ we should be using 0. Reportedly fixing this single occurrence is enough to get FG to compile, presumably somebody #defines NULL for the others (because there are tons of others). -- Cheers, Csaba/Jester -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG caching (was: Texture cache)
On Sun, Apr 3, 2011 at 11:39 PM, Tim Moore wrote: > On Sun, Apr 3, 2011 at 3:41 PM, ThorstenB wrote: >> I've also been using CACHE_ALL since then - not seeing any problems. But >> I haven't checked memory consumption. So, what's the status about the >> OSG caching options, should we enable these? Tim? > There are two issues I can think of. One is that animations might not > work correctly with caching enabled, but I think the copying we do > elsewhere should take care of that. The other is that memory usage > will be higher with caching enabled. You can say THAT again! I wonder if OSG people know that they should also throw out stuff from cache, not just put things in! I have been bold enough to use the CACHE_ALL for today's TGA multiplayer event ... at the end of the 6th hour or so, FG's memory usage reached 7.5GB, with the extensive swapping negating any eventual advantage of the caching. So, I certainly do not recommend setting this option on by default, until the behavior is fixed (such as by introducing a memory limit). -- Cheers, Csaba/Jester -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Compiler Error with Special simgear folder in Linux
On Tue, Apr 5, 2011 at 3:58 PM, Jin.Chengde wrote: > > ../../src/Network/libNetwork.a(jpg-httpd.o): In function > `HttpdImageChannel::foundTerminator()': > /home/kent/FlightGear/FlightGear/src/Network/jpg-httpd.cxx:117: > undefined reference to `trJpgFactory::render()' > > if i make and make install the simgear , then configure and make the > flightgear's source code, no error happened, So any body have any idle? > it looks like have some link error with plib's network? This is the usual problem of changing simgear configuration from jpeg factory enabled to disabled, without cleaning out the installed headers. FG's configure checks for the presence of the jpgfactory.hxx in the installed simgear headers. However, if you reconfigure simgear with jpeg factory disabled, that just means it won't install the mentioned jpgfactory.hxx, but it won't delete it either. Thus you end up with simgear libs without jpeg factory code, but the header is still there so FG thinks it can use them, resulting in link failure. -- Cheers, Csaba/Jester -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On Wed, Mar 23, 2011 at 11:38 PM, ThorstenB wrote: > > I've pushed an update to sg/fg/fgdata which enables a (so far well > hidden) feature of our "subsystem manager" to capture timing statistics. I have found that feature earlier :) Also I have actually removed some subsystems, but to no avail. Let's see if somebody can produce other results. -- Csaba/Jester -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On Tue, Mar 22, 2011 at 5:24 AM, Robert wrote: > > Ingame (insim) I notice a small stutter that happens once every second. > Did anybody of you guys notice the same thing? Yes I also see it on both of my machines (amd+ati, intel+nvidia) I have AI local traffic, traffic manager and replay disabled, too. > What can we do about it? Don't know, I have so far failed to pinpoint the source of the problem. -- Csaba/Jester -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug with Protocol handling String fields?
On Sun, Mar 6, 2011 at 1:23 AM, Csaba Halász wrote: > On Sat, Mar 5, 2011 at 6:09 PM, Roberto Inzerillo wrote: >> >> Is it FlightGear not parsing correctly the string input? Maybe attaching to >> it any \n it receives as a part of the string? > > Yes. That code could use some cleanup. > First, it calls the simgear io channel function readline() which > simply uses \n as delimiter, not knowing about the line separator > specified in the protocol file. Then, the \n is left in the buffer and > thus processed with the last chunk. Just committed a quick fix which: 1) warns if given line separator doesn't end with a newline, and adds it 2) warns if any input data doesn't end with the expected line separator 3) strips the line separator from the input Ideally, we'd have to pass down the line separator to simgear, but that's for another time. Report if I have broken something. -- Csaba/Jester -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug with Protocol handling String fields?
On Sat, Mar 5, 2011 at 6:09 PM, Roberto Inzerillo wrote: > > Is it FlightGear not parsing correctly the string input? Maybe attaching to > it any \n it receives as a part of the string? Yes. That code could use some cleanup. First, it calls the simgear io channel function readline() which simply uses \n as delimiter, not knowing about the line separator specified in the protocol file. Then, the \n is left in the buffer and thus processed with the last chunk. -- Csaba/Jester -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGrun compile problem against v.2.2 git
On Sun, Feb 20, 2011 at 11:45 AM, Harry Campigli wrote: > > make[2]: Entering directory `/usr/local/src/fgrun/fgrun/po' > rm -f fr.gmo && : -c --statistics -o fr.gmo fr.po > > Do I need to install more than just fluid ? Try installing gettext package as well. The configure script seems to be broken if it didn't report error about that. -- Csaba/Jester -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGrun compile problem against v.2.2 git
On Sat, Feb 19, 2011 at 10:44 PM, Frederic Bouvier wrote: > > Moreover, line 13 of wizard.h reads "using std::string;" Which, incidentally, is not something you like to see in header files. But I guess we can live with that in FGRun. -- Csaba/Jester -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGrun compile problem against v.2.2 git
On Sat, Feb 19, 2011 at 2:28 PM, Harry Campigli wrote: > > I find issues with building FGrun on Ubuntu 10:10 FG and SG are both > current from the git repostories FG run is v1.5.2 > > Make stops with: > In file included from wizard.cxx:7: > wizard.h:331: error: ‘string’ does not name a type > make[2]: *** [wizard.o] Error 1 > > wizard.h line 331 is : > > FlightGearThread *fgThread; Sounds like you are looking at the wrong file/line, since that line doesn't have "string" on it. > Is this an issue from compiling fgrun to the git version of FG? This is a problem in fgrun, it is missing #include and/or it has problem with properly referencing the namespace. -- Csaba/Jester -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AH-1 Merge Request
On Fri, Feb 18, 2011 at 11:55 PM, Stuart Buchanan wrote: > > Warning: Could not find plugin to read objects from file > "/home/stuart/FlightGear/fgdata/Aircraft/AH-1/Models/Cockpit/pilot1.png". > Warning: Could not find plugin to read objects from file > "/home/stuart/FlightGear/fgdata/Aircraft/AH-1/Models/Cockpit/pilot2.png". > > Is that expected, or is there an error in the zip file? Looks like quite a few of the files named .png are really jpegs: $ identify pilot1.png pilot1.png JPEG 512x512 512x512+0+0 DirectClass 8-bit 223.154kb -- Csaba/Jester -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] memory usage
I have noticed that after about an hour of hanging around at KSFO in an ufo on MP, FG's memory went steadily up and eventually reached 2.7GiB. Similarly, during the TGA event at the weekend, memory usage was above 2GiB by the end of the ~5 hour flight. Looks like we may be leaking memory. Anybody else have similar experience? I am using current GIT on 64 bit linux with AI traffic, traffic manager and replay turned off. -- Csaba/Jester -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [ANN] tyre smoke system
Seeing all the creative mess people created when trying to use tyre smoke, I have decided to add a little helper class to aircraft.nas, named tyresmoke_system. I also tweaked the existing tyresmoke class a little, but it should still be backward compatible. To use the new tyresmoke_system, all you need to do is replace your previous nasal code with a single call as follows: aircraft.tyresmoke_system.new(0, 1, 2, 3, 4); Pass the appropriate gear indices as arguments. Nothing else is needed, updates are managed automatically. I am not really happy with the physical model either, but I focused on the nasal side for now. Please report any bugs, regressions or comments. -- Cheers, Csaba/Jester -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery: airport tower positions
On Sun, Feb 13, 2011 at 2:36 PM, ThorstenB wrote: > > there are two fixes concerning the tower positions at EDLL and EGLL in > the bug tracker (see attached files EDDL.twr.xml and EGLL.twr.xml). Just to have a written record of it somewhere, let me tell you another crazy idea of mine :) I envision a system where models themselves can have predefined named view points, possibly with some attributes. This would fix the tower position problems and the model+cockpit-view issues and also allow adding notable points for sightseeing. FG could then pick appropriate positions for specialized views automatically, and present a list of nearby view points for the user to select from on request. If for some reason there is no tower model for a particular airport, the existing tower position coordinates could still be used as fallback. -- Csaba/Jester -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sinking feeling - c172 on gravel runway
On Thu, Feb 10, 2011 at 7:33 PM, Geoff McLane wrote: > > (a) John, I wanted to try your metar to see if it looked > related, but like Arnt I can not get the metar string through > the command parser! > > Always - > Fatal error: Failed to open file > at 012345Z > (received from SimGear XML Parser) > > What are we doing wrong? I don't know what you are doing wrong, but Arnt is using a stupid shell script wrapper that apparently does not handle quoted arguments with spaces in them. Thus the --metar=" 012345Z 07315KT 50SM FEW015 SCT025 BKN035 OVC090 15/M01 A3092" gets turned into --metar= 012345Z 07315KT 50SM FEW015 SCT025 BKN035 OVC090 15/M01 A3092 So only the is the argument to --metar, the rest are separate options that are considered to be property files to load. All I can say is, use the fgfs binary if you want to troubleshoot flightgear problems and not launcher/wrapper bugs :) -- Csaba/Jester -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Incorrect conversion used for lbs to gallon of fuel
On Thu, Feb 10, 2011 at 3:21 PM, henri orange wrote: > That was not my point. > I was talking about the Nasal error. I know. I just pointed out that the GIT version is broken anyway. BUT working around the missing file, it DOES now fly, without the fuel nasal error. -- Csaba/Jester -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Incorrect conversion used for lbs to gallon of fuel
On Tue, Feb 8, 2011 at 10:05 PM, henri orange wrote: > Will it solved the Boeing314 issue ? The Boeing314 in GIT doesn't even get that far, it is missing a file "Nasal/Boeing314-limits.xml" Commenting the reference out, the aircraft at least takes off. -- Csaba/Jester -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Incorrect conversion used for lbs to gallon of fuel
On Tue, Feb 8, 2011 at 9:27 PM, Torsten Dreyer wrote: >> And that is because of the hardcoded default of 8 fuel tanks. Attached >> patch makes sure at least the existing tanks are covered by the >> properties. >> > Thanks for spotting this. I was naive enough to think no aircraft ever has > more then eight tanks. Now TankProperties are created for every configured > tank in /consumeables/fuel. > > This should keep the Concorde for a bit longer again. But you have broken my patch! :) The code should specifically check for the number of "tank" subnodes (although overestimating the number is harmless). However, this doesn't work as intended: int n = rootNode->nChildren(); if( n == 0 ) n = rootNode->getIntValue( "numtanks", 8 ); Since if n is zero, that means no children whatsoever, so no "numtanks" either. Thus then it will always be 8, and can not be set via a "numtanks" property (because then n will be one). Also, Anders pointed out that more tanks may be needed even if they are not (yet) in the property tree, so ultimately the FDM should be consulted. -- Csaba/Jester -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal getprop: property /accelerations[0]/pilot[0]/z-accel-fps_sec[0] is NaN
On Mon, Feb 7, 2011 at 6:59 PM, Csaba Halász wrote: > > That is already the end of the problem chain. Somewhere NaN is > creeping into the system and propagates to various parts. Finding what > uses z-accel-fps_sec, while possible, will not help you in > troubleshooting the root cause. It might have something to do with the relocation to a mooring position. I had some hint of NaN when that happened near KSFO, but had no problems at EHAM (which doesn't have a mooring position). -- Csaba/Jester -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal getprop: property /accelerations[0]/pilot[0]/z-accel-fps_sec[0] is NaN
On Mon, Feb 7, 2011 at 6:38 PM, henri orange wrote: > Hello, devel-members, > > I am getting ( randomly ) the following messages > > Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..) > nan nan nan nan nan nan segment ignored.. > Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..) > nan nan nan nan nan nan segment ignored.. > Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..) > nan nan nan nan nan nan segment ignored.. > PT_vs_hpt: ran out of layers for h=nan > PT_vs_hpt: ran out of layers for h=nan > Nasal getprop: property /accelerations[0]/pilot[0]/z-accel-fps_sec[0] is NaN > Nasal getprop: property /accelerations[0]/pilot[0]/z-accel-fps_sec[0] is NaN > Nasal getprop: property /accelerations[0]/pilot[0]/z-accel-fps_sec[0] is NaN > > I would like to know, which feature, within flightgear is using "Nasal > getprop: property /accelerations[0]/pilot[0]/z-accel-fps_sec[0]". > I do not try to access that property, so i guess it is an internal > (automated ?) process That is already the end of the problem chain. Somewhere NaN is creeping into the system and propagates to various parts. Finding what uses z-accel-fps_sec, while possible, will not help you in troubleshooting the root cause. You might want to try using a debugger and running with the command line option --enable-fpe. -- Csaba/Jester -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Incorrect conversion used for lbs to gallon of fuel
On Sun, Feb 6, 2011 at 9:35 PM, Csaba Halász wrote:
>
> But the Concorde still doesn't fly, it now runs out of fuel after a
> few seconds. Still investigating that issue.
And that is because of the hardcoded default of 8 fuel tanks. Attached
patch makes sure at least the existing tanks are covered by the
properties.
--
Csaba/Jester
diff --git a/src/FDM/TankProperties.cxx b/src/FDM/TankProperties.cxx
index 7bd24fb..d72362c 100644
--- a/src/FDM/TankProperties.cxx
+++ b/src/FDM/TankProperties.cxx
@@ -174,6 +174,9 @@ TankPropertiesList::TankPropertiesList( SGPropertyNode_ptr
rootNode )
// we don't have a global rule how many tanks we support, so I assume eight.
// Because hard coded values suck, make it settable by a property
size_type n = rootNode->getIntValue( "numtanks", 8 );
+ // but make sure it at least covers the existing children
+ size_type existing = rootNode->getChildren( "tank" ).size();
+ if ( n < existing ) n = existing;
for( size_type i = 0; i < n; i++ ) {
push_back( new TankProperties( rootNode->getChild( "tank", i, true ) ) );
}
--
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Incorrect conversion used for lbs to gallon of fuel
On Sun, Feb 6, 2011 at 9:24 PM, Bertrand Coconnier wrote: > 2011/2/6 Torsten Dreyer : >> >> I tried the few JSBSim and YASim aircraft that I'm able to handle, please >> report if I broke anything. >> > > Have you read my previous e-mail ? I attached a patch because JSBSim > fuel calcs are broken (tested aircraft is p51d). All P51d tank > capacities, levels and fuel densities are wrongly overwritten and set > to 0.0 (except the density which is set to 6.3 lbs/gal instead of 6.02 > lbs/gal). > Jester tested my patch as well and reported it to work. Indeed it fixes the problem it is supposed to fix. But the Concorde still doesn't fly, it now runs out of fuel after a few seconds. Still investigating that issue. -- Csaba/Jester -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
On Sun, Feb 6, 2011 at 12:45 AM, henri orange wrote: > Hi, > > built OSG 2.9.10 again , and built Simgear Flightgear again gives the same > error. > > Then, since OSG 2.9.11, is available. > I have just built osg 2.9.11, > Unfortunately simgear built against it, gives the following error > What is the matter ? Current OSG is unfortunately incompatible with FG. Note, this is a compilation error, as it should be. Your earlier error with 2.9.10 was a linker error, which may mean you are not linking against all the required libraries. You have cut off the actual linker command line, so I can't tell. Have you re-run autogen.sh and configure too? -- Csaba/Jester -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reload joystick config
On Sun, Jan 30, 2011 at 8:51 PM, Frederic Bouvier wrote:
>
> But if you start without a joystick, you won't be able to open that dialog
That is true. Easily fixed by reevaluating the menu state after the
reload. Should probably be refactored a little to avoid code
duplication (I simply copied the line from gui.nas)
diff --git a/gui/menubar.xml b/gui/menubar.xml
index 0d2cc52..05c7133 100644
--- a/gui/menubar.xml
+++ b/gui/menubar.xml
@@ -571,6 +571,10 @@
reinit
input
+
+ nasal
+
gui.menuEnable("joystick-info",
size(props.globals.getNode("/input/joysticks").getChildren("js")));
+
--
Csaba/Jester
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reload joystick config
On Sun, Jan 30, 2011 at 1:58 PM, Frederic Bouvier wrote: > > I noticed three things under Windows : > 1. the state of menu entry "Help > Joystick information" is not modified > when I remove or add a joystick after start Confirmed, but unrelated to the patch. The joystick information window does however show the correct data after it is re-opened following a reload input, even if I have plugged in a different joystick in the meantime. > 2. if I do "Reload input" with the joystick already recognized, axes > goes wrong and I have to do a Reset to initialize them. > 3. if I remove the joystick while the joystick information dialog is > displayed and reload input, fgfs segfault. Don't see these problems under debian linux with plib/svn. -- Csaba/Jester -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ..what _is_ this view, a Nasal three-letter word?: "bug" is a three-letter word
On Sat, Jan 29, 2011 at 9:37 PM, Arnt Karlsen wrote:
> On Sat, 29 Jan 2011 02:15:41 +0100, Arnt wrote in message
> <20110129021541.0d04cd1b@celsius.local>:
>
>> ..and, what _is_ this view?
>> https://github.com/gasguru/flightgearthings/raw/master/ATI-nite_warriors/radeon-fgfs-screen-002.png
>
> ..found this wee snippet in my now context-trimmed console output:
> Nasal runtime error: non-objects have no members
> at /home/arnt/FG-git/install/fgfs/bin/../fgdata//Nasal/view.nas, line
> 110 called from: /input/keyboard/key[118]/binding, line 1
>
> ..line 110 is a comment, that shouldn't call a view?
> arnt@celsius:~/FG-git$ nl install/fgfs/fgdata/Nasal/view.nas |less
> ...
> 109 ##
> 110 # Standard view "slew" rate, in degrees/sec.
> 111 #
> 112 var VIEW_PAN_RATE = 60;
User error. "nl" does not count empty lines by default, but nasal
does. In any case, "less" is perfectly capable of displaying line
numbers:
$ less -N view.nas
...
108 # And pop up a nice reminder
109 var popup=getprop("/sim/view-name-popup");
110 if(popup == 1 or popup==nil)
gui.popupTip(views[n].getNode("name").getValue());
So, presumably you have encountered a view that doesn't have a name.
--
Csaba/Jester
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] "bug" is a three-letter word
On Sat, Jan 29, 2011 at 2:15 AM, Arnt Karlsen wrote: > > ..if you zoom in or get closer, do you see the missing > runway lights? Hm, no. -- Csaba/Jester -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] "bug" is a three-letter word
On Fri, Jan 28, 2011 at 8:52 PM, John Denker wrote: > It's spelled "ATI" > > On 01/27/2011 08:01 PM, Csaba Halász wrote: >> I am now running the shiny new 11.1 fglrx driver on my integrated HD4200. >> The 737-100 has some silly landing lights, but other than that, it looks >> normal. > > I just how upgraded to the 11-1 fglrx driver. > > Still no runway lights. Of course not, since the problem is in FG. The "point sprites" option has been broken since a while. ATI is innocent, I demand satisfaction :) (assuming said magical "point sprites" not working is not an ATI bug by itself) http://www.imagebam.com/image/ff01b6117146655 -- Csaba/Jester -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reload joystick config
On Fri, Jan 28, 2011 at 10:02 AM, James Turner wrote: > > On 28 Jan 2011, at 08:21, Andreas Gaeb wrote: > >> In the meantime I played around with this a little and came up with the >> attached patch which does what I describe above. This seems to work, >> though I didn't do any checks to rule out the suspected issues. > > Looks good to me, from a visual inspection. I'll apply over the weekend, and > poke some people to test. Depending on when 2.2.0 happens this might even be > worth back-porting, but we should wait for some positive testing feedback > before that. Since FG currently irreversibly loses joystick if it ever gets unplugged and replugged (or if the usb driver reconnects for some reason), and this patch allows for reinitializing the joystick, I certainly vote to get this into the release. Thanks Andreas! -- Csaba/Jester -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
