RE: [Flightgear-devel] 777 Model
Boris Koenig writes: But, there seems to be a project related to openRT that is dedicated to developing the necessary hardware: http://www.saarcor.de/ This is a fascinating project but ... until these chips are as prevalent in consumer grade hardware as OpenGL cards are today, I think we should content ourselves with just dreaming about programing FGFS in OpenRT. Note that FGFS does not utilize many of the features available in the more current generations of OpenGL cards but now that OpenGL 2.0 is a reality that may start to change in the not so distant future. This *might* make a large differance in the rendering performance although I suggest that those preoccupied with the rendering speed profile the code to see where the time is being spent. I am espescially interested in the profiling results from the newer higher end cards. i.e the GForce 4 class or equivalent cards Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Took advantage of Erik's...
Ampere K. Hardraade wrote: No. What I want to do is tell each of these animation file where the livery resides. I want to be able to tell all of them with in one single file, instead of having to create a new xml file for every animation file. Ah, That's what you meant. I don't think that multiple includes would solve this problem either. One solution might be putting the texture path into a property (and let the top-level model animation configuration file override the default) but that would mean that *every* model has to include a texture path... We would have to think a bit more about this. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Saitek Cyborg-Evo.xml broken
Dave Perry wrote: Help! Since my CH Yoke and Pedals don't work with the new joydev driver in Suse 9.1, I need to use my Saitek Cyborg Evo joystick. Both js_demo and jstest show all it's axes and buttons working but ony the non DEFANGED functions work in FlightGear (that is aileron, elevator and rudder ... no buttons). I had to edit three things in Cyborg-Evo.xml 1. The name displayed by js_demo and jstest is Saitek Cyborg USB Stick so I changed the name in the xml file. 2. Axis for hat left/right was 4 (not 6) in jstest. 3. Axis for hat fore/aft was 5 (not 7) in jstest. With these changes, only the non-DEFANGED_script functions work. Is this xml a work in progress or have I broken something else? Some day I will learn not to upgrade a working very stable system! The Cyborg-Evo.xml has all the features of a profile created for a windows user. As a reminder, axis numbering, and sometimes names, are different between Linux/Unix and Windows. The usual differences are : rudder : 3 for unix, 2 for windows throttle : 2 for unix, 3 for windows hat horizontal : 4 for unix, 6 for windows hat vertical : 5 for unix, 7 for windows Of course, you can see exceptions to that for gamepads or multi-featured joysticks but it appears to be the general case for 4-axis joysticks. To address that, and to have only one profile for any joystick, few things changed after the 0.9.4 release : axis n=number has been deprecated. You must now use the syntax below : axis descView Direction/desc number unix4/unix windows6/windows /number ... /axis You can also put as any number of names as needed. So at the top of the file : nameSaitek Cyborg Evo/name nameAlternate Saitek Cyborg Evo/name nameAnother Saitek Cyborg Evo/name and so on. These changes will hopefully prevent that successive patch to a broken profile really broke that profile for the other population of fgfs users as it has been the case in the past. Nobody is owning all the joysticks we support, so it would be nice that anybody who has submitted a profile in the past update the syntax to avoid this kind of confusions. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Saitek Cyborg-Evo.xml broken
Dave Perry wrote: Help! Since my CH Yoke and Pedals don't work with the new joydev driver in Suse 9.1, I need to use my Saitek Cyborg Evo joystick. Both js_demo and jstest show all it's axes and buttons working but ony the non DEFANGED functions work in FlightGear (that is aileron, elevator and rudder ... no buttons). I had to edit three things in Cyborg-Evo.xml 1. The name displayed by js_demo and jstest is Saitek Cyborg USB Stick so I changed the name in the xml file. 2. Axis for hat left/right was 4 (not 6) in jstest. 3. Axis for hat fore/aft was 5 (not 7) in jstest. With these changes, only the non-DEFANGED_script functions work. Is this xml a work in progress or have I broken something else? I think this is because of an OS difference. What OS are you using, we can adjust that per operating system now. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Saitek Cyborg-Evo.xml broken
Dave Perry wrote: Help! Since my CH Yoke and Pedals don't work with the new joydev driver in Suse 9.1, I need to use my Saitek Cyborg Evo joystick. Both js_demo and jstest show all it's axes and buttons working but ony the non DEFANGED functions work in FlightGear (that is aileron, elevator and rudder ... no buttons). I had to edit three things in Cyborg-Evo.xml 1. The name displayed by js_demo and jstest is Saitek Cyborg USB Stick so I changed the name in the xml file. 2. Axis for hat left/right was 4 (not 6) in jstest. 3. Axis for hat fore/aft was 5 (not 7) in jstest. With these changes, only the non-DEFANGED_script functions work. Is this xml a work in progress or have I broken something else? Some day I will learn not to upgrade a working very stable system! I don't really understand the meaning of DEFANGED, but looking at the sources, the nasal subsystem is looking for a property named script, not DEFANGED_script so I guess these scripts were deactivated by someone before inclusion. Try to rename to script and see if it works. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] lights flaring on runways in FG
On Sunday 25 July 2004 23:39, Peter Larson wrote: I get the same ground poly problems that you seem to be getting with your new ATI driver, except I've been getting them for some time now. It actually only seems to be the airfield polys that are affected but you'll often see it with airfields that are a long way away, to the extent that you can't see the airfield itself but only the displaced polys as they sick up through the haze, sometimes to many tens of thousand of feet. Are you able to fly at night i.e. when the sun is below the horizon? If I try flying in these conditions FG starts but crashes once I get a few hundred feet in the air and I think this is also due to the ATI drivers. I'm very new on FG, only been running it for two weeks. Also, my PC was just recently rebuilt, so pretty much everything in new. I was getting the segfault when I exited FG, but this disappeared when I installed the latest driver from the ATI web site. I've seen some comments that there are problems with some VIA chipsets and the ATI Radeon cards, so I have also installed the latest drivers for the motherboard. My machine was hanging when the resolution was greater than 1024 x 768, just running windows, so there is obviously some clashes there. since I did this, I havn't tried higher than 1024 resolution, so I don't know if I've actually fixed the problem. Are you using an ATI card? The problems you described are similar, especially the long distance problems. I assumed at first that is was really bad sheet lightning graphics until I noticed they were coming from the ground! Yep - I'm using an ATi card. I've had FG hang once in a night flight, possibly around 100 seconds, as others indicated in this thread. I'll pay more detail from now on, as I've assumed most of my problems up until now have been motherboard/video clashes. Peter I'm pretty certain that these problem are due to the ATI drivers - using the same FG s/w versions on other systems with old Matrox cards is fine. I've also had problems with other s/w that seems to be clearly linked to the ATI drivers too. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] trouble with generic protocol over TCP/IP
Hi I'm having trouble using it on tcp/ip, altough over serial it works as expected. i'm using other machine (192.168.0.2) with netcat (nc -l -p 5500) and firing FG on this pc(192.168.0.1) like this: $ fgfs --generic=socket,out,5,192.168.0.2,5500,tcp,osc Failed to find runway 28R at airport LPMA Initializing OpenAL sound manager Unable to load the protocol configuration file game loads as expected, no data is sent, and connection is closed when i close FG. same thing if i use f1serial (osc is just a stripped down of f1serial.xml) same thing for UDP, except that nc exits when FG starts fgfs --native=socket,out,5,192.168.0.2,5500,tcp works nice, but receiving binary data was not what i had in mind versions used are a 3 week old cvs in slackware and 0.9.4 win32 binary am i doing something wrong or generic protocol has problems over tcp/ip? Thanks in advance, Tiago ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] chase/cockpit view
hello. can anybody give me an advice how to implement new view inflightgear: a combination of cockpit and chase view - so that the plane would be looked at from behind (like in chase mode) but at the same time viewport behaviour would be the same as in cockpit - i mean precise rotation (with no delays like in chase mode, so that when you press a button the plane would rotate with the view simultaneously). hope the idea is clear. i will be glad if somebody helped me a bit... because i am not very experienced in programming and still have to learn a lot :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] trouble with generic protocol over TCP/IP
Tiago Gusmão wrote: Hi I'm having trouble using it on tcp/ip, altough over serial it works as expected. i'm using other machine (192.168.0.2) with netcat (nc -l -p 5500) and firing FG on this pc(192.168.0.1) like this: $ fgfs --generic=socket,out,5,192.168.0.2,5500,tcp,osc Failed to find runway 28R at airport LPMA Initializing OpenAL sound manager Unable to load the protocol configuration file am i doing something wrong or generic protocol has problems over tcp/ip? The generic protocol was never tested over TCP/IP. Looking at the code it doesn't work at the moment unless the file is called tcp.xml ... We need to fix that. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] trouble with generic protocol over TCP/IP
Tiago Gusmão wrote: $ fgfs --generic=socket,out,5,192.168.0.2,5500,tcp,osc Failed to find runway 28R at airport LPMA Initializing OpenAL sound manager Unable to load the protocol configuration file This is fixed in CVS and will be included in the next release of FlightGear (0.9.5). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Took advantage of Erik's...
Right now, if one wants to specify a new livery for some of the animation files, he/she will have to do this: aircraft-set.xml + main.xml [ + livery1.xml [ [ + animation1.xml [ + livery2.xml [ [ + animation2.xml [ [ + animation3.xml We can make it possible to do something like this instead: aircraft-set.xml + main.xml [ + livery.xml [ [ + animation1.xml [ [ + animation2.xml [ [ + animation3.xml Regards, Ampere On July 25, 2004 04:31 am, Erik Hofman wrote: Ampere K. Hardraade wrote: No. What I want to do is tell each of these animation file where the livery resides. I want to be able to tell all of them with in one single file, instead of having to create a new xml file for every animation file. Ah, That's what you meant. I don't think that multiple includes would solve this problem either. One solution might be putting the texture path into a property (and let the top-level model animation configuration file override the default) but that would mean that *every* model has to include a texture path... We would have to think a bit more about this. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Tried the Spitfire
Vivian Meazza wrote: I'm just working on the fuel gauge for the Spitfire, when I ralised that I haven't modeled the fuel system correctly. At present both tanks feed into the engine. What should happen is that the upper tank feeds the lower tank which feeds the engine. Is there any built-in way of doing this? One way to do this is to always make sure the lower tank is selected, and the uper one is not. Then have a Nasal timer fire at some sane frequency (mayby 5Hz) or whatnot that takes fuel out of the top tank and adds it to the bottom one according to the current pump configuration. It's not hard, really. You can look at the existing fuel.nas code for examples. The only gotcha I can think of is that the frame rate isn't constant: you want to use the time-elapsed property to calculate the amount of fuel to transfer, instead of assuming a constant amount per iteration. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Took advantage of Erik's...
Ampere K. Hardraade wrote: Right now, if one wants to specify a new livery for some of the animation files, he/she will have to do this: aircraft-set.xml + main.xml [ + livery1.xml [ [ + animation1.xml [ + livery2.xml [ [ + animation2.xml [ [ + animation3.xml Maybe I am overlooking what is involved but it seems strange to have a different animation file for each livery. Are you sure you cannot put the main animations in a file that can be included by every livery file ? -Fred We can make it possible to do something like this instead: aircraft-set.xml + main.xml [ + livery.xml [ [ + animation1.xml [ [ + animation2.xml [ [ + animation3.xml Regards, Ampere On July 25, 2004 04:31 am, Erik Hofman wrote: Ampere K. Hardraade wrote: No. What I want to do is tell each of these animation file where the livery resides. I want to be able to tell all of them with in one single file, instead of having to create a new xml file for every animation file. Ah, That's what you meant. I don't think that multiple includes would solve this problem either. One solution might be putting the texture path into a property (and let the top-level model animation configuration file override the default) but that would mean that *every* model has to include a texture path... We would have to think a bit more about this. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] trouble with generic protocol over TCP/IP
On Sunday 25 July 2004 17:37, Erik Hofman wrote: Tiago Gusmão wrote: $ fgfs --generic=socket,out,5,192.168.0.2,5500,tcp,osc Failed to find runway 28R at airport LPMA Initializing OpenAL sound manager Unable to load the protocol configuration file This is fixed in CVS and will be included in the next release of FlightGear (0.9.5). Erik Thank you! meanwhile while using tcp.xml, i noticed that using a line separator of newline actually printed the word newline (this doesn't happen in var separator), it doesn't bother me much, just reporting Is there any generic input support planned just for curiosity? Regards, Tiago ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Tried the Spitfire
Andy Ross wrote Sent: 25 July 2004 21:07 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Tried the Spitfire Vivian Meazza wrote: I'm just working on the fuel gauge for the Spitfire, when I ralised that I haven't modeled the fuel system correctly. At present both tanks feed into the engine. What should happen is that the upper tank feeds the lower tank which feeds the engine. Is there any built-in way of doing this? One way to do this is to always make sure the lower tank is selected, and the uper one is not. Then have a Nasal timer fire at some sane frequency (mayby 5Hz) or whatnot that takes fuel out of the top tank and adds it to the bottom one according to the current pump configuration. It's not hard, really. You can look at the existing fuel.nas code for examples. The only gotcha I can think of is that the frame rate isn't constant: you want to use the time-elapsed property to calculate the amount of fuel to transfer, instead of assuming a constant amount per iteration. Thanks Andy. I have already put together a Nasal script, using fuel.nas as a model. It wasn't hard, once I had figured out how to make it re-iterate. Nasal is a delight to use: doing exactly what we want. The script tries to model the fuel system. Both tanks are connected to the engine, and there is an open pipe connecting them, so fuel is transferred from the upper to the lower whenever there is room in the latter until the former is empty. So good so far - that bit works. The gotcha is that the engine stops when either tank is empty, rather than when there is no fuel in any tank. I can't see a way around that without tinkering with the logic of fuel.nas. That said, the logic of fuel does seem a little odd. Have I got my analysis of the logic wrong? Where is kill-when-empty set? I can easily adjust fuel.nas to work for the Spitfire, but of course I don't want to rot up any other model. How to proceed? Thanks again. Regards, Vivian http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Success
and it ran. I even flew it. Another glowing testimonial from a satisfied user! Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Spitfire
To create smoke, we will need two things: smoke emitter and smoke object. The smoke emitter will allow the user to set the following properties: - X, Y, Z coordinate relative to the aircraft. This is the location at which the smoke objects will be created. - vector at which the smoke is emitted. - initial velocity of the smoke relative to the aircraft. - radius of the smoke. - temperature of the smoke (useful when velocity is zero). - density/opacity of the smoke. - illumination value of the smoke in RGB. - color of the smoke. - time it takes for the smoke to become visible. - rate at which the smoke will dessipate. - time it takes for the smoke to lose illumination. - a boolean variable to control the state of the smoke emitter. When the smoke emitter is enabled, it will keep creating new smoke objects. These new smoke objects will have the following properties: - current X, Y, Z coordinates relative to the world. - velocity relative to the world. - current raidus. - time until it becomes visible. - current density. - current illumination. Unlike the smoke emitter, these properties will be completely isolated from the user. In addition, it also needs several functions to: - calculate its new velocity. - calculate its velocity relative to the smoke source. - place itself at the new coordinate. - calculate its new radius. - change its own temperature. - change its own density. - change its own illumination. - determine what type of smoke it will be (explain later). This way, the smoke can be create and forget. As for the actual visible smoke, it can can takes on several geometries. A few useful ones are: - low poly sphereical. - cylindical (for smoke ring). - dougnut/torus (for a more detail smoke ring). - a simple polygon (for low velocity smoke). Each type of geometry has its own advantages and performance issues. That's why it should be controlled by the smoke object instead of the user. In the lifetime of the smoke, these geometries will expand, change orientation, and eveuntually deform, may even change type, and finally dissipate. For the spitfire, since the smoke won't come out at very high speed during engine start, polygon should be used to represent each smoke object. Now if only some kind soul will implement this. =P To be honest, I would rather want someone to fix the framerate problem before working on eye candy. Regards, Ampere On July 22, 2004 11:06 am, Vivian Meazza wrote: I've implemented a Coffman cartridge starter, and it would be nice to have a cloud of black smoke come out of the exhaust and drift downwind at wind speed before dispersing. I can do the first bit, but not the rest. I have my eye on Fred's bump-mapped 3D clouds. Anyone any ideas on this one? (Forget it could be good advice :-) ). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Spitfire
To create smoke, we will need two things: smoke emitter and smoke object. I really hope you can do this. Smoke and fire are important for the X-15, too. :-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Spitfire
I hope so too, but the fact is: I'm not a programmer. Regards, Ampere On July 25, 2004 10:53 pm, Jon Berndt wrote: I really hope you can do this. Smoke and fire are important for the X-15, too. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
