Re: [Flightgear-devel] Weather
> Flightgear has a nice (local and global) weather implementation AFAIK. > Are there some ideas (or solutions) how to map custom or shared weather > values in a (internal or external) weather radar" ? Someone was working on that, and we got to the point that Advanced Weather writes thunderstorm info into the wxradar section of the property tree. If the wxradar ever picked up that info and displayed anything I don't know. If you're interested in pursuing this further, it's easy to extend to include other precipitation info. Basically the concept is that the wxradar gets a very abstract set of data and 'fakes' a plausible display, because if you would acutally display the rain distribution we generate under a storm, you'd see a very nice and utterly unrealistic circle :-) * 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_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Weather
Hi all Flightgear has a nice (local and global) weather implementation AFAIK. Are there some ideas (or solutions) how to map custom or shared weather values in a (internal or external) weather radar" ? -Yves -- 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_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery not being loaded
Am 11.11.2012 19:05, schrieb Geoff McLane:
> That's strange no one has done this for WIN32 ;=()
I guess most Windows people are using launchers. It's mainly Linux
people who love command-lines ;-).
> #if defined(_WIN32)
> // with absPath NULL, will allocate, and ignore length
> char *buf = _fullpath( NULL, path.c_str(), _MAX_PATH );
> if (!buf) {
>SG_LOG(... as per unix ...);
>return path; // failed, return path as is
> }
> std::string p(buf);
> free(buf); // was allocated using malloc(), so
> return p;
Thanks. I have committed it, but can't test it myself. Can some check
with latest SimGear if relative paths are working for Windows now - with
standard MSVC build (check for "Nasal ... not found" errors).
Actually, thinking about it: cygwin is POSIX, so it can use the POSIX
implementation.
I'm not sure if the compiler switches in sgpath are really correct - it
assumes normal "Windows" paths for cygwin (WIN32 is also defined for
cygwin). I guess Cygwin isn't really well maintained for FG right now.
Patches welcome... ;-)
cheers,
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_nov
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery not being loaded
On Sun, 2012-11-11 at 18:04 +0100, ThorstenB wrote:
> If anyone was interested/able to fix the support for relative paths on
> Windows, please implement "SGPath::realpath" in simgear/misc/sg_path.cxx:
>
Hi Thorsten,
re: std::string SGPAth::realpath() const
That's strange no one has done this for WIN32 ;=()
Do NOT know about the MAC, but WIN32 has always,
ALWAYS had, in -
char *_fullpath( char *absPath, const
char *relPath, size_t maxlength );
So that gives something very similar to realpath()...
#if defined(_WIN32)
// with absPath NULL, will allocate, and ignore length
char *buf = _fullpath( NULL, path.c_str(), _MAX_PATH );
if (!buf) {
SG_LOG(... as per unix ...);
return path; // failed, return path as is
}
std::string p(buf);
free(buf); // was allocated using malloc(), so
return p;
#elsif defined(_APPLE_) && (MAC_OS_X_VERSION_MAX_ALLOWED <= 1050)
return path;
#else
// current unix code
...
#endif
And although I do not have a lot of experience with
Cygwin I understand it knows how to convert a DOS/
Windows path to its unix kludge, /c/..., so do not
need to do anything special... but maybe...
But this is all aside from the possible 'bug'
Jon is pointing out...
HTH,
Regards,
Geoff.
--
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_nov
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery not being loaded
> Well, I've tried all sorts of combinations of pathnames, using > different path name specification forms (windows, linux, etc.) and I > can get FlightGear to run using several of the forms - and to load the > scenery I desire, as well - I cannot get both the custom scenery and > the HUD symbology to work at the same time. Note that I am using the > external FDM, if that makes a difference. > > Using full pathnames I was able to get rid of the Nasal errors - and > now have no errors, but like I wrote, I still can't get both the HUD > and custom scenery at the same time. :-( > > I'm currently suggesting that this is a bug. > > Jon BTW, the form I used that seems to work for path names in a Cygwin bash shell under Windows Vista 64 is: export FG_ROOT="C:\\cygwin\\home\\jon\\FlightGear\\data" export FG_SCENERY=" C:\\cygwin\\home\\jon\\FlightGear\\scenery" Jon -- 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_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery not being loaded
Well, I've tried all sorts of combinations of pathnames, using different path name specification forms (windows, linux, etc.) and I can get FlightGear to run using several of the forms - and to load the scenery I desire, as well - I cannot get both the custom scenery and the HUD symbology to work at the same time. Note that I am using the external FDM, if that makes a difference. Using full pathnames I was able to get rid of the Nasal errors - and now have no errors, but like I wrote, I still can't get both the HUD and custom scenery at the same time. :-( I'm currently suggesting that this is a bug. Jon -- 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_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery not being loaded
Am 11.11.2012 18:23, schrieb Jon S. Berndt: > Thanks for the reply. The path handling in FlightGear seems a bit delicate. > Not sure if in Cygwin under Windows I need to be more unix-like, or more > windows-like in specifying paths. I'll play with that some, but relative > paths do work - at least selectively, for some things. Yes, they work in some areas. But they don't work for Nasal and some other areas. To avoid the issues you really need to use absolute paths - whatever kind works for Cygwin... For Cygwin, instead of "c:\FlightGear", try /c/FlightGear/... or c:/FlightGear/... cheers, 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_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery not being loaded
> Am 11.11.2012 17:39, schrieb Jon S. Berndt: > > Also, if I specify only the custom scenery path - as in the command > > line below - I get the errors that follow. Don't know if those are > > revealing or unexpected ... > > > > bin/Win64/fgfs.exe --fg-root=./data --fg-scenery=./scenery > > --aircraft=CitationX --native-fdm=socket,in,30,,5550,udp > > --fdm=external --airport=KCHS > > > > Cannot find Nasal script './data/Nasal/local_weather ... > > Aha... You must not use relative paths on Windows. Only absolute paths > are supported. Thanks for the reply. The path handling in FlightGear seems a bit delicate. Not sure if in Cygwin under Windows I need to be more unix-like, or more windows-like in specifying paths. I'll play with that some, but relative paths do work - at least selectively, for some things. I tried full unix-style path names, and that didn't work at all (couldn't find the base package). Jon -- 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_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery not being loaded
Am 11.11.2012 17:39, schrieb Jon S. Berndt:
> Also, if I specify only the custom scenery path - as in the command line
> below - I get the errors that follow. Don't know if those are revealing or
> unexpected ...
>
> bin/Win64/fgfs.exe --fg-root=./data --fg-scenery=./scenery
> --aircraft=CitationX --native-fdm=socket,in,30,,5550,udp --fdm=external
> --airport=KCHS
>
> Cannot find Nasal script './data/Nasal/local_weather ...
Aha... You must not use relative paths on Windows. Only absolute paths
are supported.
If anyone was interested/able to fix the support for relative paths on
Windows, please implement "SGPath::realpath" in simgear/misc/sg_path.cxx:
> std::string SGPath::realpath() const
> {
> #if defined(_WIN32) || (defined(__APPLE__) && MAC_OS_X_VERSION_MAX_ALLOWED <=
> 1050)
> // Not implemented for Windows yet. Return original path instead.
>
> #else
> ...
This code is supposed to convert a relative path (given in command-line
parameters) into a proper absolute path - since we have several places
in FG, which just cannot deal with relative paths.
cheers,
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_nov
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery not being loaded
Also, if I specify only the custom scenery path - as in the command line below - I get the errors that follow. Don't know if those are revealing or unexpected ... bin/Win64/fgfs.exe --fg-root=./data --fg-scenery=./scenery --aircraft=CitationX --native-fdm=socket,in,30,,5550,udp --fdm=external --airport=KCHS Cannot find Nasal script './data/Nasal/local_weather ... ... Nasal runtime error: non-objects have no members ... Jon > -Original Message- > From: Jon S. Berndt [mailto:jonsber...@comcast.net] > Sent: Sunday, November 11, 2012 9:33 AM > To: 'FlightGear developers discussions' > Subject: Re: [Flightgear-devel] Scenery not being loaded > > > When the HUD no longer works, make sure you haven't deleted anything > > in FGDATA - like the fonts. You don't need to define the path to the > > base scenery (within fgdata). If you downloaded additional scenery, > in > > one or multiple separate directories, you can separate the paths with > ":" > > (works also on Windows). > > > > fgfs --fg-root=FGDATA_PATH --fg-scenery=CUSTOM_PATH1:CUSTOM_PATH2:... > > > > cheers, > > Thorsten > > Still no HUD symbology with the custom scenery. If I leave out the -- > fg-scenery option on the command line, I don't get my custom scenery, > but I *do* get the HUD symbology. If I add in the --fg-scenery option, > I do get the custom scenery, but not the HUD symbology. :-) > > Jon > > > > --- > --- > 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_nov > ___ > 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_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery not being loaded
> When the HUD no longer works, make sure you haven't deleted anything in > FGDATA - like the fonts. You don't need to define the path to the base > scenery (within fgdata). If you downloaded additional scenery, in one > or multiple separate directories, you can separate the paths with ":" > (works also on Windows). > > fgfs --fg-root=FGDATA_PATH --fg-scenery=CUSTOM_PATH1:CUSTOM_PATH2:... > > cheers, > Thorsten Still no HUD symbology with the custom scenery. If I leave out the --fg-scenery option on the command line, I don't get my custom scenery, but I *do* get the HUD symbology. If I add in the --fg-scenery option, I do get the custom scenery, but not the HUD symbology. :-) Jon -- 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_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Moonlight reloaded
> You need to do High Dynamic Range rendering to accurately capture these > differences and the eye's ability to adapt to them. Basically, you do all > the rendering in floating point and at the end convert the values to RGB > colors with a mapping operator. We don't do that yet. I'm currently rendering scenes illuminated between 10.000 lux and 0.1 lux (i.e. a range of 100.000 in luminous flux) just fine without High Dynamic Range. I'm entirely happy with the visual impression of light reduction under overcast skies or with self-shading of fog. The trick is that I do the log before rendering, High Dynamic Range does it after rendering. I can do so, because my scene is dominated by a single light source which is either sun or moon, so I never need to compare the strength of different light sources. I'm not happy with high light intensity situations like looking directly into the sun, but that's because I haven't done it, not that I couldn't do it - I have the scheme worked out, but since I don't know when I'm looking into the sun, I can't implement it. We're not trying to solve the general problem, so we don't need the general solution to get the job done. We just need a particular solution for a particular job which covers 99% of the situations you can encounter in flight, and that happens to be way cheaper. Also, note that High Dynamic Range isn't accurate either - beyond Weber Fechner, the details of light perception happen to be really messy and once we are in simulating the details of the visual cortex, adding higher accuracy doesn't really help you :-) * 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_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Moonlight reloaded
On Sun, Nov 11, 2012 at 1:41 PM, Renk Thorsten wrote: > > I suspect the difference in light intensity > > (dynamic range) doesn't fit in an 8-bit 3-component color. > > It sure doesn't, but I think you're thinking way too complex. We don't > want to render physical light intensity, we want to render perceived light > intensity, and there the Weber Fechner law is relevant, and that says that > we roughly want to render the log of the physical light intensity. > > For instenace, full daylight has 10,000 lux, and a very dark overcast day > has 100 lux - yet if you multiply the sun (rgb) = (1,1,1) which works fine > for a sunny day with 0.01, you don't get an overcast day - 0.6 is more the > factor you need, i.e. every factor 10 reduction in luminous flux is about > -0.2 from the base light. > > A full moon has about 0.1 - 1 lux, so we get (rgb) values of ~(0.1..0.2) > in the light vector - which works visually just fine (I've been using > vec3 moonLightColor = vec3 (0.095, 0.095, 0.15) * moonlight * scattering; > for the pics) - which gives imo a decent visual appearance. > > You need to do High Dynamic Range rendering to accurately capture these differences and the eye's ability to adapt to them. Basically, you do all the rendering in floating point and at the end convert the values to RGB colors with a mapping operator. We don't do that yet. Tim -- 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_nov___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flight recorder / replay system
Am 11.11.2012 10:52, schrieb Thomas Geymayer:
> Everything works great here. Save own flights, playback own and your
> flights (Nice approach btw.;) ). Only with jsbsim the "my controls"
> button is missing, but that wasn't working before neither...
Good. ;-)
Right, the "my controls" button is currently intentionally disabled for
JSBSim and for YASim helicopters. Only works with YASim aircraft so far.
YASim reads in all relevant properties before each iteration, so any
external change to a property (aircraft angle, velocity) takes immediate
effect. This is why it is easy to just take over control of a "replay
session": when the replay system has restored the state of all relevant
properties, we can just reenable the FDM calculation - and YASim just
takes it from there and continues.
Unfortunately that's different with YASim helicopters: the rotor speed
(pretty much the most important property of a helicopter) isn't read
from the property tree. So, if you took over control in mid-air, YASim
ignores the rotor speed set by the replay system - and the helicopter
dropped like a stone. I tried to fix this a while ago, but it turned out
to be more complex than expected.
It's the same issue with JSBSim, if I remember correctly. It doesn't
read (at least not all) properties prior to an iteration, so external
changes to aircraft properties don't have any effect.
It's possible to start JSBSim with a given velocity/angle/.. though,
like we do when initially starting FlightGear or trigger a simulator
reset. However, we currently can't just reinitialize or tear down and
recreate a single subsystem - at least that is currently not working
with the FDM subsystem. The whole (re)initialization phase has a lot of
dependencies and fixed sequences. So that currently also isn't an option.
The hope is that will change. We have already cleaned up a lot of
subsystem / initialization things over the past year - and more things
are planned. Eventually, I hope we can just recreate an FDM at any time
("out of thin air"... ;-) ) with arbitrary initial settings.
cheers,
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_nov
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Moonlight reloaded
> I suspect the difference in light intensity > (dynamic range) doesn't fit in an 8-bit 3-component color. It sure doesn't, but I think you're thinking way too complex. We don't want to render physical light intensity, we want to render perceived light intensity, and there the Weber Fechner law is relevant, and that says that we roughly want to render the log of the physical light intensity. For instenace, full daylight has 10,000 lux, and a very dark overcast day has 100 lux - yet if you multiply the sun (rgb) = (1,1,1) which works fine for a sunny day with 0.01, you don't get an overcast day - 0.6 is more the factor you need, i.e. every factor 10 reduction in luminous flux is about -0.2 from the base light. A full moon has about 0.1 - 1 lux, so we get (rgb) values of ~(0.1..0.2) in the light vector - which works visually just fine (I've been using vec3 moonLightColor = vec3 (0.095, 0.095, 0.15) * moonlight * scattering; for the pics) - which gives imo a decent visual appearance. For the same reason, I don't see why we shouldn't be able to render sun glare with 8bit colors. All it takes is to store the light intensity in a separate variable and post-process the rgb output with a light-intensity dependent filter. My problem is not coming up with the filter, my problem is rather to determine if I should be blinded by the sun or if it's obscured by a panel. Btw. - I noticed that yesterday - are we by any chance doing any rendering tricks at night? Immediately after dusk, the moonlight renders fine, but after a while when it gets really dark, it suddenly snaps to a circle of illumination around me and everything else is pitch black. Is there any old code assigning a trivial ambient and diffuse material to faraway scenery to speed up rendering hidden somewhere, or should I look for a very exotic shader bug? Cheers, * 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_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery not being loaded
Am 11.11.2012 13:14, schrieb Frederic Bouvier:
>> multiple separate directories, you can separate the paths with ":"
>> (works also on Windows).
>>
>> fgfs --fg-root=FGDATA_PATH --fg-scenery=CUSTOM_PATH1:CUSTOM_PATH2:...
>
> On windows, the path separator if ";"
You are right, for scenery it indeed is. But I'm sure I have seen a
"funny" hack in our code somewhere, which detected if the ":" character
was preceded by a single or multiple letters - in order to distinguish
Windows drive specs (i.e. "C:\foo..") from actual path separators
("C:\foo:A:\bar). But maybe this hack is in another area - or it was
dumped...
cheers,
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_nov
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d clouds on multi-display systems (was Re: FSWeekend 2012...)
> I think that's just a side-effect of having so many pixels covered by > (multiple) quads with alpha. I'm not sure there's much we can do > about that, unless we somehow start dropping sprites. I'll have a > think - 3D cloud perf has always been a big challenge. Based on my own experiments, I agree. If we have 20 sprites in the cloud and the cloud covers the whole screen, the fragment shader does at last 20 texture lookups per pixel - which are pretty expensive. It's basically the equivalent of rendering the urban effect on the whole screen (anyone here who can do this with good framerates? - I get about 6 fps if I try...) There's one thing we could try which might help a bit - in addition to texture lookup, the fragment shader also fogs the clouds. If we don't do fogging for nearby clouds (i.e. the ones which cover the whole screen), we don't really change the visuals, but save 20+ repetitions of fogging computation. An alternative option would be to not render really close cloud by texture at all (= drop fragments based on a distance cut) and replace them by a procedurally generated pattern. This may be rather tricky to get right, but if the function isn't too complicated, it may be cheapter than to read textures, and we'd get hires closeups as a bonus. Dropping sprites certainly helps, but it takes away the feeling of volume - which is especially important for nearby clouds. :-( * Thorsten * 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_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery not being loaded
> multiple separate directories, you can separate the paths with ":" > (works also on Windows). > > fgfs --fg-root=FGDATA_PATH --fg-scenery=CUSTOM_PATH1:CUSTOM_PATH2:... On windows, the path separator if ";" -Fred -- 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_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery not being loaded
Am 11.11.2012 05:32, schrieb Jon S. Berndt: > I have a new problem, now, though. I do see the scenery (when I get under > about 6000 feet - until then I see only white fog) since I gave the path to > the directory outside $FG_ROOT where I placed the terrain, but now I no > longer get proper HUD symbology - the numbers aren't there anymore. Any > suggestions on how I can do this? I'm not sure how I can set two scenery > paths on the cygwin command line for starting FlightGear. When the HUD no longer works, make sure you haven't deleted anything in FGDATA - like the fonts. You don't need to define the path to the base scenery (within fgdata). If you downloaded additional scenery, in one or multiple separate directories, you can separate the paths with ":" (works also on Windows). fgfs --fg-root=FGDATA_PATH --fg-scenery=CUSTOM_PATH1:CUSTOM_PATH2:... cheers, 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_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flight recorder / replay system
Hi Thorsten, really great news. I already thought that something like this would be very cool :) Everything works great here. Save own flights, playback own and your flights (Nice approach btw. ;) ). Only with jsbsim the "my controls" button is missing, but that wasn't working before neither... 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_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
