Re: [Flightgear-devel] Iceland textures
Did you test your airfield grass with some of the newer generated terrain (LOWI in my case)? No, I didn't. Shouldn't make a difference for rendering purposes how you created it, at this stage it's all vertices and pixels and the shaders don't care where they come from or how they connect. Not sure about the airfield grass, but at least the concrete and tar surfaces for taxiways and apron use a different mapping. If i remember correctly 1 x 1 meter in the new scenery builds. I'm not sure I understand the problem. After the scenery generation process, you have vector data of the terrain mesh, but textures are mapped at tile load time using materials.xml - so here we find that a 512x512 sheet of terrain is mapped to, say, 2000x2000 m. This is done independent of how the vector resolution of the terrain mesh is and has nothing to do with how you generated the scenery. You're also usually not free to change the mapping as you like - texture sheets depict real-world structures with a real-world size, and showing 1000 m sized houses on the texture just doesn't do. Shader effects add noise and overlay textures to the base texture mapping, and here is where it gets tricky: * Overlay textures inherit the uv-mapping of the base texture sheet for lookup purposes (you can't look them up in world or local cartesian coordinates), and read the overlay texture at a fixed fraction of the base texture uv coordinates. Which means that if you shrink the base texture, normal maps, heightmaps and overlay structures shrink proportionally. This makes sense - imagine the urban effect in which you change the scale of the base texture but not of the heightmap - suddenly random bits of the base texture show the relief. * Procedural noise is usually generated at fixed scale in world coordinates or local cartesian coordinates - this needs to be so because you need to be able to fade it out at a given distance to avoid Moire patterns and flickering, and also because the noise often stands for some fixed-size phenomenon (rocks lying around, ocean waves...) So texture size mapping declarations and shader-internal noise mappings can in general not be varied arbitrarily or independently and need to be considered together. It would be possible to code shaders in which overlay textures are also done at fixed physical sizes - but you'd need a lot of extra parameters to do that and I'm not really sure in improves usability. If that's what you're doing, i.e. you're changing the mapping of a base texture to a physical size, my recommendation is just to undo these changes or to map your airports to a different effect in materials.xml. The reason is that we have a balance between what details we want to generate procedurally and what details need to be on a texture. Some structures (grass for instance, agriculture patterns, buildings) need to be on the texture sheet because the functions to generate them are very expensive, other more random structures can more cheaply be generated by evaluating a function. So in the case of fields we use a top-down approach - the fields which we can't do by function are shown in the texture, the local grainy detail structure is done in the shader. The airfield grass uses a bottom-up strategy - the grass which isn't easily generated by a function is done by a hires texture mapping, this leads to tiling when seen at larger scales, so shader-generated noise is used to de-tile the effect. If you come with a different idea of the base texture size, you may need to change the whole approach from top-down to bottom-up or at least the balance between what detail scales are on the texture and what detail scale you add procedurally. I admit that it's not exactly convenient that all these things need to be taken into account when doing texturing together with effects, but it's very hard to write an effect like the airfield grass or the runway that will work with any base texture you could come up with - the issues listed above are not going to go away easily. I don't know if that is the issue, but perhaps the explanation makes sense (?) * Thorsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Air-to-air refuelling enhancement
Le 24/02/2013 23:44, Stuart Buchanan a écrit :
Hi All,
I've just committed some small changes to the AI air-to-air refueling
function:
1) Added support for multiple tankers of each type, selectable through
the AI-Tankers GUI. Tankers are now defined in AI/tankers.xml.
2) Added an A-4F buddy tanker.
3) Enhanced the UI to allow the user to set the speed of the tanker,
and the radius at which contact is made. Note that this is based on
the origin of tanker and user. As a future enhancement I want to add
offsets to indicate the position of the refuelling probe/receiver
on the user aircraft, and the location of the boom/drogue on the tanker.
4) Added a user-toggled function to display messages when contact i
made or lost. Some aircraft
don't seem to have any obvious cockpit indicator that refuelling is in
progress, and we don't currently animate the probe being in the drogue
:)
5) Added maximum fuel flow definitions to both the tanker and
receiver. While the KC-135 supports
flow of 6000 lbs/min, smaller tankers (such as the A4-F buddy tanker)
only provided ~1300 lbs/min. the actual fuel flow is taken as the
minimum of the two.
Note that the maximum fuel flow affects both AI and MP tankers. I've
been unable to test with the latter, but have set a default to ensure
backwards compatibility.
Feedback welcome as always.
-Stuart
hi Stuart,
after a few runs behind ai tankers, and some crashs in the sky, i think
the a4f need to have at least the drogue and hose not hot.
here's a diff :
--- a/Models/Geometry/A4-F/a4-f-tanker.xml
+++ b/Models/Geometry/A4-F/a4-f-tanker.xml
@@ -14,6 +14,12 @@
object-nameFixedCanopyGlass/object-name
object-nameCanopy_1/object-name
/effect
+
+ animation
+ object-nameHose/object-name
+ object-nameDrogue/object-name
+ enable-hotfalse/enable-hot
+ /animation
model
pathPilot/pilot.xml/path
the radius definitely need the offsets , i was unable to make contact in
the usual position with a short radius :)
when you're in tanker.nas , I think that in turns, the tanker don't have
a rotation correct respect to the bank angle, when you follow you don't
have the same bank angle and it's a bit strange. here i got a much
better behaviour with this patch:
--- a/Nasal/tanker.nas
+++ b/Nasal/tanker.nas
@@ -155,7 +155,7 @@ var Tanker = {
}
var distance = dt * (me.ktas - me.headwind) * NM2M / 3600;
- var deviation = me.roll ? 0.5 * dt * 1085.941 *
math.tan(me.roll * D2R) / me.ktas : 0;
+ var deviation = me.roll ? dt * 1085.941 *
math.tan(me.roll * D2R) / me.ktas : 0;
if (me.mode == leg) {
if (me.lastmode != leg) {
jano
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Advanced Weather updates
On 1 Mar 2013, at 07:53, Renk Thorsten thorsten.i.r...@jyu.fi wrote: However, the change does mean that if you leave the visibility at cruise altitudes of airliners at 10 km, you will not get to see many clouds regardless of how the cloud visibility range is set (because they now respect the real visibility setting in addition), so this is potentially an issue for Basic Weather users. If this is a show-stopper, then we may need to undo the changes, but fading to alpha is by far the fastest way to deal with heavily fogged clouds. This feels like a moderately large issue to me, because out of the box, we select basic weather, and hence we're going to get bug reports about clouds not appearing. We could make basic weather drive the real visibility based on altitude, but then we're moving away from 'basic weather does what you set'. We could give basic weather sea-level and altitude visibility and interpolate between them, which I guess is what advanced weather does? And of course if we drive 'real' visibility in that way, we're back to upsetting the performance of people who are using visibility range to modulate performance. Suggestion: rename cloud 'visibility' distance to 'draw distance' (since it's in the rendering dialog anyway), to make it clear it's nothing to do with weather / environment in basic weather, have clouds ignore environment/visibility, and simply use draw distance (as before) in advanced weather, cloud use the minimum of both, and get fogged, with nice results in low vis situations. This assumes distinguishing weather models i the cloud code is possible, of course. James -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Advanced Weather updates
On 1 Mar 2013, at 07:53, Renk Thorsten thorsten.i.r...@jyu.fi wrote: One problemhere is that rain textures are still orphaned (i.e. don't move in the wind with the clouds) - I'm running out of ideas here - my Nasal moving code creates frame spacing issues, Vivian's C++ moving code patch wasn't accepted, so I'd appreciate a helping hand from C++ coders before the next release. I need someone to reset my brain on this, explain to me what functionality is required, show me the Nasal code and Vivian's version, and so on. James -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Advanced Weather updates
This feels like a moderately large issue to me, because out of the box, we select basic weather, and hence we're going to get bug reports about clouds not appearing. We could make basic weather drive the real visibility based on altitude, but then we're moving away from 'basic weather does what you set'. We could give basic weather sea-level and altitude visibility and interpolate between them, which I guess is what advanced weather does? Well, the problem arises because a number of issues have so far been handled in a peculiar way: * Basic Weather 'out of the box' assumes, when driven with METAR, that the reported visibility has no altitude dependence (I think) - which isn't particularly realistic in the first place * clouds, unlike practically all other objects, do not really respect visibility the same way as other objects (they are fogged in the default rendering scheme at twice the nominal visibility, so a similar issue exists outside Atmospheric Light Scattering and clouds disappear before their rendering cutoff hits... * ... but Atmospheric Light scattering, unlike the default scheme, gives you always a rather clear skydome once you clear the ground haze layer as long as no extra high-altitude haze is declared, so in essence the visibility above the lowest layer certainly looks visually very high (this is intended since it gives you a realistic appearance of very clear air high up and the illusion of having several hundred km visibility) One could fix either of those: Changing aloft visibility in Basic Weather leads to memory issues. Not fading clouds leads to bad behaviour in low visibility. And fogging the skydome to agree with the set visibility leads to a completely unrealistic visual impression at high altitudes - 10 km forward visibility at airliner cruise altitude outside of cloud layers simply do not occur. So I'm not quite sure what the intended behaviour should be. Obviously, if you expect to see objects 70 km away with 10 km visibility set, there's something fishy with your expectation as well. And saying that you want to use visibility for memory management but otherwise have a realistic visual impression of objects 100 km away is also not quite a honest base expectation... Suggestion: rename cloud 'visibility' distance to 'draw distance' (since it's in the rendering dialog anyway), to make it clear it's nothing to do with weather / environment Sounds good to me - make that perhaps 'max. draw distance'. in basic weather, have clouds ignore environment/visibility, and simply use draw distance (as before) in advanced weather, cloud use the minimum of both, and get fogged, with nice results in low vis situations. That's in essence asking to code a dependence on the active weather system into the shader, and that's something which imo smells like bad design. The shader shouldn't have to care how the properties which drive it are created. Can a Basic Weather user perhaps test if there is a substantial problem at all, i.e. if 3d clouds disappear as compared with expectations when running Basic Weather and Atmospheric Light Scattering? Maybe we're trying to come up with a fix for a rather theoretical issue... * Thorsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Advanced Weather updates
I need someone to reset my brain on this, explain to me what functionality is required, show me the Nasal code and Vivian's version, and so on. Rain layers and Cirrus clouds are not shader-generated 3d stacks of sprites like the 3d clouds but normal, Nasal-spawned models. 3d clouds are moved by changing the transformation matrix (I guess). But we have no way of moving Nasal-spawned objects except updating their position from a Nasal loop every frame (we do have hardcoded movement for AI-objects, but Nasal-spawned objects cannot use that for some reason - so the Nasal tanker has such a per-frame update loop). It turns out that per-frame position updates for O(20-30) objects from Nasal is already too much to keep a nice and smooth framerate above 20 fps. So I de-activated the Nasal loop. The functionality needed is that, like AI objects, Nasal-spawned models can get a heading and a velocity and then move automatically as specified. Vivian, do you still have the patch somewhere? It's somewhere on my old computer... * Thorsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Low visibility issues
On Thu, Feb 21, 2013 at 10:54 AM, Stuart Buchanan stuar...@gmail.com wrote: On Thu, Feb 21, 2013 at 12:59 PM, James Turner wrote: Suggestion - if z/Z are pressed with advanced weather enabled, make the popup-message say 'disabled since visibility is being controlled by advanced weather'. Another option would be to move the visibility control to a dialog, with a slider / spin box, and explicitly disable it when advanced weather is selection. Then we could lose the keybinding completely, which is something I want to move towards for options that are infrequently used, but taking up 'keyboard space'. I agree that it shouldn't be a keyboard assignment, and we should remove it. On Fri, Mar 1, 2013 at 8:02 AM, Renk Thorsten thorsten.i.r...@jyu.fi wrote: I don't think any of this is a real issue or under debate at the moment (?) - the whole discussion about z/Z is if the keybinding should be removed [...] *Please* don't drop the z/Z key binding. This is one of the most useful and direct controls we have to affect the visual experience. It allows the user to directly control the view out the window, trade off visuals for frame rate and smoothness on older hardware or complex scenery, and trade off realism of flight experience for the simple pleasure of looking out the window for those more into tourism. It can be useful for modifying a built-in weather scenario that's close but not exactly what is wanted. In short, it allows even the newest user to control their FlightGear visual experience according to their particular use case and need for realism. I have no problem at all with disabling the keys when (say) advanced weather is selected, but for several classes of users and types of use, it really is an important capability and is used often. Gary -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Low visibility issues
On 2 Mar 2013, at 17:09, Gary Carvell gary.carv...@gmail.com wrote: I have no problem at all with disabling the keys when (say) advanced weather is selected, but for several classes of users and types of use, it really is an important capability and is used often. I don't see anything in your list, that wouldn't work as a slider in a suitable GUI dialog. (Which dialog it is, is a question to be decided, for sure) The advantage there being we can disable the slider, when advanced weather is selected, and provide a label explaining *why*. James -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Advanced Weather updates
James Turner wrote: On 1 Mar 2013, at 07:53, Renk Thorsten thorsten.i.r...@jyu.fi wrote: One problemhere is that rain textures are still orphaned (i.e. don't move in the wind with the clouds) - I'm running out of ideas here - my Nasal moving code creates frame spacing issues, Vivian's C++ moving code patch wasn't accepted, so I'd appreciate a helping hand from C++ coders before the next release. I need someone to reset my brain on this, explain to me what functionality is required, show me the Nasal code and Vivian's version, and so on. I'd forgotten about that. I think my patch is long since gone - probably lost it here at least 1 hdd ago. I'll scratch around a bit and see if anything remains. Vivian -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Low visibility issues
Gary Carvell wrote: On Thu, Feb 21, 2013 at 10:54 AM, Stuart Buchanan stuar...@gmail.com wrote: On Thu, Feb 21, 2013 at 12:59 PM, James Turner wrote: Suggestion - if z/Z are pressed with advanced weather enabled, make the popup-message say 'disabled since visibility is being controlled by advanced weather'. Another option would be to move the visibility control to a dialog, with a slider / spin box, and explicitly disable it when advanced weather is selection. Then we could lose the keybinding completely, which is something I want to move towards for options that are infrequently used, but taking up 'keyboard space'. I agree that it shouldn't be a keyboard assignment, and we should remove it. On Fri, Mar 1, 2013 at 8:02 AM, Renk Thorsten thorsten.i.r...@jyu.fi wrote: I don't think any of this is a real issue or under debate at the moment (?) - the whole discussion about z/Z is if the keybinding should be removed [...] *Please* don't drop the z/Z key binding. This is one of the most useful and direct controls we have to affect the visual experience. It allows the user to directly control the view out the window, trade off visuals for frame rate and smoothness on older hardware or complex scenery, and trade off realism of flight experience for the simple pleasure of looking out the window for those more into tourism. It can be useful for modifying a built-in weather scenario that's close but not exactly what is wanted. In short, it allows even the newest user to control their FlightGear visual experience according to their particular use case and need for realism. I have no problem at all with disabling the keys when (say) advanced weather is selected, but for several classes of users and types of use, it really is an important capability and is used often. I agree. I am just finishing a patch which leaves z/Z as is for Basic Weather, but makes z/Z control max vis. for Detailed Weather, just like the slider in the menu. Should give us the best of both worlds. Testing atm, should be in fgdata soon. Vivian -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Low visibility issues
James Turner On 2 Mar 2013, at 17:09, Gary Carvell gary.carv...@gmail.com wrote: I have no problem at all with disabling the keys when (say) advanced weather is selected, but for several classes of users and types of use, it really is an important capability and is used often. I don't see anything in your list, that wouldn't work as a slider in a suitable GUI dialog. (Which dialog it is, is a question to be decided, for sure) The advantage there being we can disable the slider, when advanced weather is selected, and provide a label explaining *why*. It's fecking difficult to operate a mouse/menu/slider while using a joystick unless you are ambidextrous (which I'm not). And even then I shouldn't think it easy. You can try using the Detailed Weather/Advanced Settings. There is absolutely no need to disable z/Z in Detailed Weather. It ain't broke - could we avoid fixing it and turn our attention to something that is like memory usage or moving clouds? Vivian -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adds on FlightGear.org
I realize this is not a satisfactory response for some people, but I have added downloadmanagerapp.com to the list of blocked sites. Thanks, Curt. On Fri, Mar 1, 2013 at 2:34 PM, Anders Gidenstam anders-...@gidenstam.orgwrote: On Fri, 1 Mar 2013, Gijs de Rooy wrote: Curt, are you there? Repeating the links in case you missed them: http://www.flightsim.com/vbfs/content.php?13546-FlightGear-v2-10-Is-Released#comments http://www.flightsim.com/vbfs/showthread.php?260718-FlightGear-2-10-is-now-available-!p=1747315#post1747315 When I look at our main page I see Google chooses to display a very big fat green download button for some crud software in the ad-slot that is slightly to the left but otherwise right in the middle of the page. And another one further down. It looks ugly and could confuse the unwary. If it is not possible to be more restrictive on what ads to show (and even if that can be done I'm sure the guys paying for these sort of ads would do their best to by-pass any such restriction) then IMO the ads should go. Maybe the text ads could stay but the big blobs - no, thank you. Is the hosting really that expensive that we can't raise enough donations to cover it? (I have to admit I have not donated to FG, though.) Cheers, Anders -- --- Anders Gidenstam WWW: http://gitorious.org/anders-hangar http://www.gidenstam.org/FlightGear/ -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Daily Builds
Just to let everyone know, I'm having (roughly) daily builds of FlightGear and Simgear for Ubuntu users at https://code.launchpad.net/~saiarcot895/+archive/flightgear-edge. If you are interested, you can add the PPA using the instructions on the page. Note that the data files are not provided. -- Saikrishna Arcot -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to get my bug fix into the git?
Hi Tom, I have seem [1], and I don't think it is caused by the linking problem, I check and experimented the cmake parameter, it's more likely the implementation of the function in visual studio that's causing it. (the malloc() within the strdup() is probably using a different heap than the outside free()) And I don't think what I did only hides the symptoms, since _strdup() is OK to use in the windows environment. But I do believe the best solution is to replace this function. If that's required, just let me know, I can replace it and create a new merge. Thanks! Godspeed -Original Message- From: Thomas Geymayer [mailto:tom...@gmail.com] Sent: Friday, March 01, 2013 4:22 PM To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] How to get my bug fix into the git? Hi Godspeed, Am 2013-03-01 10:14, schrieb Zhitao Li: I am new to the FlightGear project, I just found and fixed my first bug, Great ;) I'm not sure if your fix [2] is really a fix or just hiding symptoms. I currently have no VS available for testing but eg. at [1] it seems like its a linking problem instead. I am wondering how to get my fix into the main git next branch? You can always open a merge request into the next branch at gitorious. Tom [1] http://stackoverflow.com/questions/8740500/heap-corruption-with-strdup?rq=1 [2] https://gitorious.org/~plutonium/fg/plutoniums-simgear/commit/0455e8f3253a2b c26e4a34265e1227984408713a -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org Student of Computer Science @ Graz University of Technology --- Austria -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to get my bug fix into the git?
Am 2013-03-03 00:49, schrieb Zhitao Li: I have seem [1], and I don't think it is caused by the linking problem, I check and experimented the cmake parameter, it's more likely the implementation of the function in visual studio that's causing it. (the malloc() within the strdup() is probably using a different heap than the outside free()) As I normally don't use Windows/VS I don't know if this is really possible. Anyhow, I have just pushed a fix which replaces the manual string copying with directly using std::string. Please test if this also solves your problem. Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org Student of Computer Science @ Graz University of Technology --- Austria -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Daily Builds
On Sat, 2 Mar 2013, Saikrishna Arcot wrote: Just to let everyone know, I'm having (roughly) daily builds of FlightGear and Simgear for Ubuntu users at https://code.launchpad.net/~saiarcot895/+archive/flightgear-edge. If you are interested, you can add the PPA using the instructions on the page. Note that the data files are not provided. How is this different from the Linux builds at http://flightgear.simpits.org:8080 ? g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Daily Builds
It automatically updates every week or so (or whatever the user's update settings are), and there's not much manual intervention required. The downsides are that this is for Ubuntu only (and maybe alternate Ubuntu distros (Kubuntu, Xubuntu, etc.)), changes require sudo privileges, and some builds may not work correctly. Saikrishna Arcot On Sat 02 Mar 2013 06:20:55 PM CST, geneb wrote: On Sat, 2 Mar 2013, Saikrishna Arcot wrote: Just to let everyone know, I'm having (roughly) daily builds of FlightGear and Simgear for Ubuntu users at https://code.launchpad.net/~saiarcot895/+archive/flightgear-edge. If you are interested, you can add the PPA using the instructions on the page. Note that the data files are not provided. How is this different from the Linux builds at http://flightgear.simpits.org:8080 ? g. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to get my bug fix into the git?
Thanks Tom, I believe your commit has fixed the specific problem, however, there is more similar string related heap corruptions popping up in the debug mode, I think I can try to fix them in a similar way you did to fix this one, if it's OK Thanks. Godspeed -Original Message- From: Thomas Geymayer [mailto:tom...@gmail.com] Sent: Saturday, March 02, 2013 5:20 PM To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] How to get my bug fix into the git? Am 2013-03-03 00:49, schrieb Zhitao Li: I have seem [1], and I don't think it is caused by the linking problem, I check and experimented the cmake parameter, it's more likely the implementation of the function in visual studio that's causing it. (the malloc() within the strdup() is probably using a different heap than the outside free()) As I normally don't use Windows/VS I don't know if this is really possible. Anyhow, I have just pushed a fix which replaces the manual string copying with directly using std::string. Please test if this also solves your problem. Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org Student of Computer Science @ Graz University of Technology --- Austria -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Low visibility issues
*Please* don't drop the z/Z key binding. This is one of the most useful and direct controls we have to affect the visual experience. (...) It's fecking difficult to operate a mouse/menu/slider while using a joystick unless you are ambidextrous (which I'm not) Can anyone please explain to me why one needs to change visibility manually during flight so often? We're trying to create a simulated experience. Which means that for me there are things which I adjust before flying, i.e. I set the airplane, the location, the weather, the environment, the time,... And there are things which I can adjust in-flight - there's the throttle, levers for gear, flaps, various buttons, where I look and what I focus on. But the simulated environment in-flight largely is what it is if you aim for realism of the experience - if the weather deteriorates, I have to deal with it. If the visibility drops below VFR conditions, I have to change my plans. Conceptually, I understand that key bindings make sense in the context of a simulator standing for things I can do in-flight in the cockpit, because I may need to be able to perform these actions quickly or while I'm doing something else (like controlling an airplane). In many cases, we do not have a keybinding, and performing a real possible action ends up being awkward - you need to mouse-click something while flying on, or you even need to open an menu. Changing visibility magically is not of this group, it's not a realistic option which you could perform in a real cockpit. I understand that visibility needs to be manually controllable for setting up specific training conditions. But this doesn't need to happen in-flight all the time and can be from the menu. I understand that visibility has a role for memory management, but that doesn't need to be done in-flight either, memory management can be done much more efficiently by setting a max. visibility value once and just store it. You can't micro-manage memory consumption by adjusting visibility all the time because a) you'd need to have an open system monitor to see memory occupancy and b) you'd need to know in advance how much memory the next tiles to be loaded will have. About the only reason why I can see one would want to adjust visibility often in-flight is 'cheating' - you just take a quick look in bad visibility where you are. This is fine, it's a simulation after all, we have AP support for planes which have no AP in reality and an in-built GPS - but why do we need to support that with a key-binding? The question to me is not 'Do some people use it?' The question we should answer is 'Given the alternative between a key binding to change visibility and assigning a new key-binding to a function you can actually perform in a cockpit, isn't the second option better'? For instance assume we would assign z/Z to changing the NAV1 frequency or the heading of the AP - these are functions which I perform basically all the time when I don't do pure VFR and it's rather awkward to open the menu or hit a tiny clickspot. Personally, I think reserving key binding for things which you can really do in a real cockpit is not a bad concept. And I would really like to understand why some people think it's necessary to change the visibility so often that a menu option doesn't work for them whereas I need to change my NAV frequencies in the menu (while flying the plane with the mouse... I can do this with just one control device) * Thorsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
