Re: [Flightgear-devel] ver 1 scenery
Hi all! Syd wrote: > CYVR has been destroyed ! :) > NO island anymore , and the delta has dried up and been converted to > farmland ... This looks like the same effect leading to the problems in Nice and elsewhere. I'm still at it, but my schedule was quite unfortunate in past weeks. Note, however, that CYVR (the airport) is displayed correctly. Cheers, Ralf - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ver 1 scenery
Ralf Gerlich wrote: > Hi all! > > Syd wrote: > >> CYVR has been destroyed ! :) >> NO island anymore , and the delta has dried up and been converted to >> farmland ... >> > > This looks like the same effect leading to the problems in Nice and > elsewhere. I'm still at it, but my schedule was quite unfortunate in > past weeks. > > Note, however, that CYVR (the airport) is displayed correctly. > > Cheers, > Ralf > > yes the airport itself looks better ... harder to align my buildings now > though ;) Syd - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] foo-set.xml -> foo-yasim-set.xml
* Syd -- Saturday 19 April 2008: > can you name an example so I can see what you mean ? My vote would > be to do something about it , so if mine are like this [...] I haven't looked closely, but I didn't refer to your aircraft. You get a good impression if you try this: $ ls $FG_ROOT/Aircraft/*/*-yasim-set.xml 90% of them add two entries to the --show-aircraft output for no good reason. (Nobody will do a Farman-IV-jsbsim-set.xml within the next century. And if so, then we can still add the necessary files in time. :-) m. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Weekly CVS Changelog Summary: SimGear
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-04-14_01:27:26 (fredb) /var/cvs/SimGear-0.3/source/projects/VC7.1/SimGear.vcproj Update MSVC 7.1 projects =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-04-14_16:44:21 (timoore) /var/cvs/SimGear-0.3/source/simgear/math/Math.hxx rewrite of sky dome code Add more points to the dome, giving it a dome shape rather than a dunce cap shape. Represent as OpenGL DrawElements instead of as triangle strips. Only calculate have the sky colors and reflect those across the dome. 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flash with altitude change
Hi!
On Saturday 19 April 2008 Curtis Olson wrote:
>>Would it be possible to introduce a bit of smoothing on your end, so that
>>the aircraft position updates
>>are more smooth and continuous? If nothing else it would be interesting
>>to see if this fixes your
>>problem, and also to see how much smoothing is required to make the
>>problem go away.
External programm should not drive FG view. I provide 100Hz FDM data for
FlightGear, is it low rate? The problem is that update of some systems must
be synchronized, and we have to define this systems.
I look CVS for Melchior fix. May be some was missed (I am using PLIB
version) but jitting is present. Now its level is acceptable. May be it will
be removed if using something similar to
if ( global_multi_loop > 0) {
globals->get_viewmgr()->update(delta_time_sec);
}
Now I roll back to 0.9.10 it is more stable for me. I have check a
number of airplanes and found that at 1.0.0 I can fly without problems UFO
only.
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] foo-set.xml -> foo-yasim-set.xml
On sam 19 avril 2008, Melchior FRANZ wrote: > There are more and more aircraft in CVS with two *-set.xml > files, where one is basically empty and only referring to > a second one. This is understandable in cases where actually > more than one FDM is used or very likely to be used in the > next time. But it's becoming a problem if this redundant > stuff is routinely added for no good reason. This makes the > output of --show-aircraft, the list in fgrun, or the output > of an --aircraft= shell completion script unusable, while it > has no real advantage. > > I considered to strip all redundant *-set.xml files out in > --show-aircraft (everything that contains one of > yasim/jsbsim/uiuc/base) and to only show that with > --show-aircraft --verbose. But that wouldn't fix the fgrun > and shell problem, and not even those subtypes are used > consistently. > > Or should we just watch the cancer and not do anything? :-} > > m. > > > Hello, I have, at least, one aircraft which could be involved with your remark, Blackbird and Blackbird-B are the same (Blackbird linked to Blackbird-B-set.xml). It had an history reason. If not useful, now, i can remove Blackbird-set.xml. Blackbird-A and Blackbird-B both variant each other, are the basic ones. Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Controlling FlightGear FDM through generic inputwith UDP
Hi! On Friday, April 18, 2008 Haluk Sevener wrote: >> How can I run the master-slave model with generic i/o interface? >>How can I control a FG instance with over network using generic interface >>with socket input option? (I failed doing this >> one. maybe my input >>format in the xml configuration is invalid. but it's ok for the output >>stuff.) What options your using to start FlightGear with generic i/o? Check your .xml file carefully. It should contain tags and with the similar chunks. Master writes to the socket chunks from and the Slave reads from . If input chunks does not correspond to output chunks, your can get "strange" results. If your have wrote a C++ code to handle incoming messages, now try to change your C++ code to drive FG using position and orientation only. I am using generic protocol to drive FlightGear from external program. Protocol was changed to use binary i/o, not only binary output as it is done in current CVS code. With respect, Alex - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Controlling FlightGear FDM through generic inputwith UDP
Thanks for your reply, All I want to do is just send the commands to a FlightGear instance over network with UDP, at the same time listening the properties of the aircraft over network by using the same protocol. In other words, I want to implement an external control mechanism. I tested to see whether this is likely to work or not, I started a master which would send current properties with generic socket output, and I started a slave which would get the properties. But this is wrong I think, because I must send controls to the slave, not the properties. Anyway, I started the instances with the following commands: (master) fgfs --generic=socket,out,1000,127.0.0.1,7755,udp,udptest (slave) fgfs --generic=socket,in,1000,127.0.0.1,7755,udp,udptest My intention is not actually do it the master-slave way, but with an external monitor-and-control system. Thanks for your attention and sorry for poor info. On 4/20/08, Alex Buzin <[EMAIL PROTECTED]> wrote: > Hi! > > On Friday, April 18, 2008 Haluk Sevener wrote: > > >> How can I run the master-slave model with generic i/o interface? > >>How can I control a FG instance with over network using generic interface > >>with socket input option? (I failed doing this >> one. maybe my input > >>format in the xml configuration is invalid. but it's ok for the output > >>stuff.) > > What options your using to start FlightGear with generic i/o? > Check your .xml file carefully. It should contain tags > and with the similar chunks. Master writes to the socket > chunks from and the Slave reads from . If > input chunks does not correspond to output chunks, your can get "strange" > results. > If your have wrote a C++ code to handle incoming messages, now try to > change your C++ code to drive FG using position and orientation only. > I am using generic protocol to drive FlightGear from external program. > Protocol was changed to use binary i/o, not only binary output as it is done > in current CVS code. > > > With respect, > Alex > > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Generic Headshake/G-compression
Hi All, Enthused by a comment on the forum by snork (http://www.flightgear.org/forums/viewtopic.php?t=1333), I've been working on an extension to the generic blackout/redout script which attempts to simulate the feeling of compression due to g-forces, by moving the pilot viewpoint vertically depending on the apparent g-force. This is a simplified version of what vivian, Josh et al. created for the Buccaneer and other aircraft. Of course, the main advantage of this is that it is completely generic, and pretty lightweight too. The overhead ontop of the redout/blackout is minimal: one extra property read/write per frame, only when the feature is enabled and in cockpit view. A patch for this is available from http://www.nanjika.co.uk/flightgear/headshake.patch Comments are very welcome, but I'm particularly interested in peoples views on the following: 1) Obviously this duplicates some aircraft-specific code, and one can argue that this sort of feature is only important for high-energy jets, where it should be modelled in more detail than I have done. I've been playing with this code on the Stampe, A4-F and Pitts, and have felt that it has improved the feeling of realism, but then I wrote it ;) Do people feel it is worth providing a generic implementation, given that for most GA flying is at 2g or less, and this will move the pilot viewpoint 5cm! 2) Currently the redout and headshake enabling properties are userarchive, which (as I understand it) means that the user's preference will over-write any aircraft setting. Given that both these generic features duplicate existing aircraft-specific code, I think I should remove this flag, so aircraft designers can over-ride it. Any comments? 3) At the moment, this feature is limited to the y-offset of the pilot viewpoint. For non-military aircraft, the most significant g-forces will be felt in the y-axis (in the pilots frame of reference), as they cannot yaw fast enough to cause any in the x-axis, and they don't have enough power to cause any in the z-axis. If it is worth providing a generic feature, is it worth making it multi-dimensional? -Stuart __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Generic Headshake/G-compression
On Sun, 2008-04-20 at 12:55 -0700, Stuart Buchanan wrote: > Hi All, > > Enthused by a comment on the forum by snork > (http://www.flightgear.org/forums/viewtopic.php?t=1333), I've been > working on an extension to the generic blackout/redout script which > attempts to simulate the feeling of compression due to g-forces, by > moving the pilot viewpoint vertically depending on the apparent > g-force. > > This is a simplified version of what vivian, Josh et al. created for > the Buccaneer and other aircraft. > > Of course, the main advantage of this is that it is completely > generic, and pretty lightweight too. The overhead ontop of the > redout/blackout is minimal: one extra property read/write per frame, > only when the feature is enabled and in cockpit view. > > A patch for this is available from > http://www.nanjika.co.uk/flightgear/headshake.patch > > Comments are very welcome, but I'm particularly interested in peoples > views on the following: > > 1) Obviously this duplicates some aircraft-specific code, and one can > argue that this sort of feature is only important for high-energy > jets, where it should be modelled in more detail than I have done. > I've been playing with this code on the Stampe, A4-F and Pitts, and > have felt that it has improved the feeling of realism, but then I > wrote it ;) Do people feel it is worth providing a generic > implementation, given that for most GA flying is at 2g or less, and > this will move the pilot viewpoint 5cm! It is worthwhile to model generically. Many aircraft in CVS could benefit from this feature without having to recode it for each. > 2) Currently the redout and headshake enabling properties are > userarchive, which (as I understand it) means that the user's > preference will over-write any aircraft setting. Given that both these > generic features duplicate existing aircraft-specific code, I think I > should remove this flag, so aircraft designers can over-ride it. Any > comments? STRONGLY OPPOSE. User preference should absolutely outweigh the aircraft designer. While I might feel, as an aircraft designer, that a function adds a degree of realism, I can't and don't test on different hardware, monitor resolutions, multi-head setups, hardware simulator setups, etc. which head-shake may cause problems with. I personally find it annoying to have the panels jumping around during IFR flight. > 3) At the moment, this feature is limited to the y-offset of the pilot > viewpoint. For non-military aircraft, the most significant g-forces > will be felt in the y-axis (in the pilots frame of reference), as they > cannot yaw fast enough to cause any in the x-axis, and they don't have > enough power to cause any in the z-axis. If it is worth providing a > generic feature, is it worth making it multi-dimensional? It may be worth while to add. Perhaps it could be used to give a sense of slip/skid for the GA pilot. Ron - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Generic Headshake/G-compression
Stuart Buchanan wrote: > Hi All, > > Enthused by a comment on the forum by snork > (http://www.flightgear.org/forums/viewtopic.php?t=1333), I've been working on > an extension to the generic blackout/redout script which attempts to simulate > the feeling of compression due to g-forces, by moving the pilot viewpoint > vertically depending on the apparent g-force. > > This is a simplified version of what vivian, Josh et al. created for the > Buccaneer and other aircraft. > > Of course, the main advantage of this is that it is completely generic, and > pretty lightweight too. The overhead ontop of the redout/blackout is minimal: > one extra property read/write per frame, only when the feature is enabled and > in cockpit view. > > A patch for this is available from > http://www.nanjika.co.uk/flightgear/headshake.patch > > Comments are very welcome, but I'm particularly interested in peoples views > on the following: > > 1) Obviously this duplicates some aircraft-specific code, and one can argue > that this sort of feature is only important for high-energy jets, where it > should be modelled in more detail than I have done. I've been playing with > this code on the Stampe, A4-F and Pitts, and have felt that it has improved > the feeling of realism, but then I wrote it ;) Do people feel it is worth > providing a generic implementation, given that for most GA flying is at 2g or > less, and this will move the pilot viewpoint 5cm! > > 2) Currently the redout and headshake enabling properties are userarchive, > which (as I understand it) means that the user's preference will over-write > any aircraft setting. Given that both these generic features duplicate > existing aircraft-specific code, I think I should remove this flag, so > aircraft designers can over-ride it. Any comments? > > 3) At the moment, this feature is limited to the y-offset of the pilot > viewpoint. For non-military aircraft, the most significant g-forces will be > felt in the y-axis (in the pilots frame of reference), as they cannot yaw > fast enough to cause any in the x-axis, and they don't have enough power to > cause any in the z-axis. If it is worth providing a generic feature, is it > worth making it multi-dimensional? > > -Stuart > > Hi Stuart , I had this option long long ago in all my aircraft , but Martin Spot claimed that it was unrealistic , so I removed it ... the old code is still in the 787 (which is a modification of the 777 Justin and I worked on ) , and the A6M2 has the code in jwarbirds.nas ... Personally , I like the effect :) Cheers Syd - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
