Re: [Flightgear-devel] Driving real instruments.
John Wojnaroski wrote: Dave Martin wrote: Unfortunately my total lack of software development skills and apparent numerical dyslexia would preclude this. That is, unless now or in the future enough people might become interested in doing this (I may not code but I'm quite the engineer when it comes to physical stuff ;) ) I think I could drive an ASI, AI, TC, VSI and engine guages using Phidgets just by writing FG values to a phidgets device in the correct sense but anything more is rocket-science to me due to the code involved. http://www.f15sim.com/index.html is a website you might try. He is using Phidgets to drive some of his gauges. Don't have the details. Phidgets are insanely easy to drive. Right now the only gauges I'm driving are 1 custom built steam gauges for the oil hyd pressure. They use ultra-micro Futaba servos with a 2:1 gear ratio to drive the pointer. You might want to head over to http://www.mikesflightdeck.com if you want to see how to scratch build your own gear. g. -- I'm not crazy, I'm plausibly off-nominal! Proud owner of 80-0007 http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Free simulator of the Frecce
Martin Spott wrote: Gene Buckle wrote: Martin Spott wrote: Arnt Karlsen wrote: ..since we do have guns now in FG, and since Slobodan's shills didn't dare challenge my rulings ;o) on Geneva Convention disputes in soc.culture.yugoslavia, alt.war.yugoslavia etc a decade ago, I believe we can code both a kill score AI engine, and a war crime score AI, basing the latter on the full 4 Geneva Conventions. I heavily object because this lets FlightGear definitely cross the line between serious simulation and war games, *rolls eyes* Stopping that might facilitate reading and thinking WTF? What makes you think Serious Simulation and War Game is mutually exclusive? g. -- -- I'm not crazy, I'm plausibly off-nominal! Proud owner of 80-0007 http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Free simulator of the Frecce
Martin Spott wrote: Arnt Karlsen wrote: ..since we do have guns now in FG, and since Slobodan's shills didn't dare challenge my rulings ;o) on Geneva Convention disputes in soc.culture.yugoslavia, alt.war.yugoslavia etc a decade ago, I believe we can code both a kill score AI engine, and a war crime score AI, basing the latter on the full 4 Geneva Conventions. I heavily object because this lets FlightGear definitely cross the line between serious simulation and war games, *rolls eyes* g. -- -- I'm not crazy, I'm plausibly off-nominal! Proud owner of 80-0007 http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Free simulator of the Frecce Tricoloriaerobatic jet
Dave Martin wrote: On Friday 29 July 2005 14:18, Arnt Karlsen wrote: ..and, this latter bit can get us some seriously fat funding: FlightGear helps war game authors teach soldiers how to prevent war crimes. Or even just helps Fight Pilots avoid Friendly-Fire incidents ;) Better yet, Helps Fighter Pilots from becoming Fighter Pile-Its. :) g. -- -- I'm not crazy, I'm plausibly off-nominal! Proud owner of 80-0007 http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Completely OT (but aviation related.)
Jon Stockill wrote: Curtis L. Olson wrote: I was curious about the idea of removing the case from my Linksys WRT54G wireless router and powering that by battery. Supposedly it's running linux and is hackable, but I haven't played around with trying to hack into it yet. How much space do you actually have? Would a nano-itx or even mini-itx board fit? With one of those you could use a USB wireless interface, giving you flexibility to position it for best signal (radome style bulge under the aircraft? :-) Hmmm. FlightWAP! :) g. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] poll
By flying under the terrain you means like flying in a tunnel under a montain ? I think it's improbable. And how would you manage landing on ground or water if one can fly under them ? What happens when the FDM system is used for ground based vehicles that _could_ enter a tunnel? g. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] lock-on
Unbelievable. Where have we come to? http://www.lockon.ru/movies/Collisions%201%20thumbnail.wmv http://www.lockon.ru/movies/Virtual%20stunt%201%20thumbnail.wmv Heheh. Yep, those boys at Eagle Dynamics know their stuff for sure. Thanks to the incessant beggin by myself and others, the new data exports in the 1.1 version is just about everything I need to run the full cockpit. g. -- I'm not crazy, I'm plausibly off-nominal! Proud owner of 80-0007 http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Trajectory show when replay?
If people thought such a feature might have wider uses it would be easy to make a simple generic marker object that could be used by all a/c. Stunt smoke like they use at airshows. g. -- I'm not crazy, I'm plausibly off-nominal! Proud owner of 80-0007 http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] f15.xml
Eric L Hathaway wrote: The attached patch modifies the JSBSim config file for the f15. Hey thanks! I haven't looked at the F-15 model for ages. The model itself should be pretty accurate (given the data and the source of the data) but if you want to improve it, please go ahead. I have dreams of someday trying to implement a reasonably accurate model of the F-15's FCS, using information available on Gene Buckle's web site, http://www.f15sim.com (look in the Operation section), and from some NASA reports. If somebody is already working on this, I'd be interested in helping. You might contact Gene Buckle about this (http://www.f15sim.com/) he has gathered quite a bit for the F-15, including a real cockpit ...) Wow. People actually _read_ all the stuff I post there? I'm impressed. :) If you guys need any help, let me know. g. -- I'm not crazy, I'm plausibly off-nominal! Proud owner of 80-0007 http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] f15.xml
I have dreams of someday trying to implement a reasonably accurate model of the F-15's FCS, using information available on Gene Buckle's web site, http://www.f15sim.com (look in the Operation section), and from some NASA reports. If somebody is already working on this, I'd be interested in helping. You might contact Gene Buckle about this (http://www.f15sim.com/) he has gathered quite a bit for the F-15, including a real cockpit ...) Wow. People actually _read_ all the stuff I post there? I'm impressed. :) If you guys need any help, let me know. Yuck, I must have read his email before I had coffee this morning, he already mentioned you site. Duh! Hehe. It is caffeine alone that sets my mind in motion. It is through beans of java that thoughts acquire speed, that hands acquire shakes, that shakes become a warning, it is by caffine alone I set my mind in motion. I don't know if you've had a chance to read the whole 5 part series but there is a lot of great information on how the longitudinal and lateral control systems work. The trick will be to make it work correctly when the CAS is off or failed. The F-15 flies like a Lincoln-Contiental with four flat tires when the CAS is off. g. -- I'm not crazy, I'm plausibly off-nominal! Proud owner of 80-0007 http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
Now let's see. What's the Cd of a human - 1.0 - 1.3? Area seated astride a booomb - 4 sq ft? Make allowance for silly hat - 2 sq ft? Yup, we can do that. I love it. You can have a special parameter for it: slim_pickens=1. :) G -- I'm not crazy, I'm plausibly off-nominal! Proud owner of 80-0007 http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Radio Hardware.
The HUD for the F-15 is a real one. Only the combining glasses are home made. The HUD optics came out on the short end of the stick in the crash of the jet it was in. The original combiners are made of .250 quartz glass with some kind of semi-reflective coating. I've been told that the coating is gold. Have you checked places that sell laser stuff ? You might be able to get mirrors with semi-reflective coating. Those mirrors I've seen might be gold coated, the color looks like it could be gold. The main problem is cost. Even if I could afford to have a new set of combining glass made, the main reflection mirror needs to be replaced to. That little gem is a front-surface mirror that definately uses gold. It's just too costly for me to worry about right now. I've got a ton of other things that will nickel and dime me to death long before I get to rebuilding the HUD. I may end up stealing parts out of the working A7 HUD I have. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: ..bo!, was: [Flightgear-devel] Back online
Just create a library that is OpenGL compatible, and you're free to do anything that frightens the rest of us. ..http://sam.zoy.org/projects/libcaca/caca-sabre.png scary enough? ;-) Great, now I have troubles getting to sleep. Try playing TTY Quake in the darkon a VT100... g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Radio Hardware.
you win! anyone who's willing to fabricate their own HUD i think should take the prize (or title, or whatever) if there is one. if you don't mind my asking, though, are you a single guy? or do you have the ability to filter out high decibel audio??? The HUD for the F-15 is a real one. Only the combining glasses are home made. The HUD optics came out on the short end of the stick in the crash of the jet it was in. The original combiners are made of .250 quartz glass with some kind of semi-reflective coating. I've been told that the coating is gold. I haven't been keeping a close eye on the hardware discussion, but interfacing to FG is very easy. I hope to be able to do some work with interfacing Manuel's (sp?) hardware for a how-to I've been picking at for the past few months. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Radio Hardware.
the prize (or title, or whatever) if there is one. if you don't mind my asking, though, are you a single guy? or do you have the ability to filter out high decibel audio??? ...forgot this bit.. :) I am in fact married. She's a very good and understanding woman. Besides, she knows the alternative is beer and strip clubs. :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Radio Hardware.
Gene Buckle wrote: others engaged in this activity. i fell a little less like a reclusive nut case :) Heh. Someone mentions nutcases, and I feel obligated to speak up. :) See http://www/f15sim.com for the precise definition of nutcase. See www.737simguy.com, www.737sim.com, 737flightsim.com and www.simpits.org for further examples. *grin* Gene, in case you were wondering, www.nut-case.com looks like an open domain right now. You might want to consider jumping on it before someone else beats you to it. :-) Naw, if I did that, what would you sane people have to aspire to? :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-flightmodel] Question: Level A FAA certified flight dynamics models
Curt, are you sure you're not talking about a Level D simulator? AFAIK, Level A is the minimum acceptable standard, with no motion base. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: bo105 + patch
* Alex Romosan -- Saturday 07 August 2004 00:36: you can clearly hear the woman say that if you lift the collective you increase the pitch of the blades so you get more lift and you'll go up. so it would seem that collective up means helicopter goes up. maybe in austria they do it differently. Chauvinist bullshit ends every discussion, thanks. Ok, I'm lost here. All he was doing was explaining what the instructor on the video was saying. Loosen up and unbolt, will ya? Jeeze. :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] atc speach
Does the ATC currently have speach or is it just printed at the top? Might I suggest linking in the festival text-to-speach library for this? What really sucks is that ATC is missing speech too. *grin* g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Newsletter
Just thought of this - Flight Notes g. On Fri, 4 Jun 2004, Erik Hofman wrote: John Wojnaroski wrote: Jon Berndt wrote: What's the status on the FlightGear newsletter? Did a name ever get chosen? The list has been narrowed and will be announced with the first issue. Which will be published as soon as we have enough articles There was a new one that popped up in my kind a few weeks back: Raging Mustang This because of our official logo. 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] [OT, article] Memphis Belle pilot passes away
I hope this doesn't offend anyone's sensitivities, but from a purely Only because it's from fox news. Don't bother wasting time on a reply, just eat shit Tex. What a wildly inappropriate response. Are you mad at old bomber pilots or something? I've met him, I thought he was a really cool gent. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: COLLISION DETECTION: possible or not?
At a minimum, the simulator should freeze with a message denoting a destructive contact or out of bounds attitude. For instance, the MD-83 sim at Alaska Airlines is configured to freeze if the bank angle exceeds 45 degrees - they don't want their pilots doing that unless it's absolutely necessary. ..dude. This is another common wisdom? I can understand 'not allowing it with paying passengers'. But I won't ever put my ass in a spam can driven by some clueless burger flippers who has never been _allowed_to_learn_ how to get out of trouble. It's strictly for paying-passengers kind of procedures. The bank angle limiter is not active during FAA checkouts. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: COLLISION DETECTION: possible or not?
Arnt Karlsen wrote: ..dude. This is another common wisdom? I can understand 'not allowing it with paying passengers'. But I won't ever put my ass in a spam can driven by some clueless burger flippers who has never been _allowed_to_learn_ how to get out of trouble. ..the IMHO appropriate way, is produce a report on violation on regulation with a big nice fat fine to pay. Crashes generate obscene forces. Many of these high end simulators are connected to motion platforms. People don't want to break their hardware. This is quite correct. The MD-83 sim cab has a 5000lb counterweight to help balance the weight of the flight deck itself. It's on a hydraulic hexapod that's driven with a 4 diameter main feed hydraulic line that's at 2150 PSI. It can fling that 10,000lb+ simulator cab around like it weighed nothing. It is mounted to a 10 foot thick concrete pad that is isolated from the rest of the building foundation by a 1 inch thick rubber seal. This prevents the vibration and motion of the simulator from collapsing the building. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: COLLISION DETECTION: possible or not?
Nah, how about: +---+ | We regret to inform you that your son was | | killed because he was stupid. | | | | +--+ | | | OK | | | +--+ | +---+ You get bonus points for knowing the quote. *laughs* g. On Sat, 1 May 2004, Ampere K. Hardraade wrote: Yes, that is nice. However, I would like to see the plane get torn into pieces, explosions, fire and blacksmoke. So we should have something like this: +-+ | Collision detected. Crash scene is | being played. | Press OK when you finish watching. | | +--+ | | OK | | +--+ +-+ Regards, Ampere On April 30, 2004 05:34 pm, Melchior FRANZ wrote: * Erik Hofman -- Friday 30 April 2004 23:16: I was thinking more small Nasal script, in the line of: +-+ | Collision detected. Simulation halted. | | | Press OK to restart. | | | +--+ | | | | OK | | | | +--+ | +-+ Looks good. (But now I want to keep my crash sound. :-) m. ___ 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] flightgear and hardware: mailinglist created
You could've saved yourself the effort and joined the simpits-tech mailing list at http://www.simpits.org. There's over 300 people on the list. g. On Fri, 30 Apr 2004, Manuel Bessler wrote: Hi all, I've created a mailinglist for those of us who build hardware, homecockpits and such. Although it is primarily targetted at those people who use flightgear, discussing how to hook up your hardware to other sims is also ok. (There are already tons of forums and mailinglists for the M$FS hardware builder crowds out there already, so this list will probably be pretty much fgfs centric) We have talked about this in the past on flightgear-devel, but hardware related threads pop up only very occasionally, so I thought this new list might be a more 'on topic' for us who just want to share their latest success stories, DIY yokes, homecockpit pics and so on. Of course, you don't have to be building anything to join. I hope that this list will be a good place to share the newest advances in home cockpit building :-) The temporary address of the list is http://m18s17.vlinux.de/cgi-bin/mailman/listinfo/sim-hardware you can also subscribe by sending a mail to [EMAIL PROTECTED] Have fun, Manuel ___ 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] flightgear and hardware: mailinglist created
On Fri, 30 Apr 2004 09:56:08 -0700 (PDT) Gene Buckle wrote: You could've saved yourself the effort and joined the simpits-tech mailing list at http://www.simpits.org. There's over 300 people on the list. I AM on that list :) I've even posted a few times. Since I now have my own server with full access, I thought I might as well set up mailman, might come in handy someday :) Hehehe. And then... simpits is not fgfs specific. Most discussions tend to be fighter pit based and mostly on MSFS or Falcon. There's not a whole lot of FGFS discussion because it's not a drop and go solution like MSFS or Falcon (and soon to be Lock On: Modern Air Combat) is. If it was easier for non-programmer types to interface to, I'm sure more people would use it. Having a FlightGear cockpit evangelist wouldn't hurt either. :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aircraft Todo List
The FC adjusts the flap settings to optimal performance under _all_ circumstances. I have yet to read somewhere there is a flap override for the F-16. Hmmm. I knew there was a reason I didn't like that airplane. :) You can see the leading edge slats responding to the FCS trying to fulfill the pilot's wish here: http://www.avweb.com/newspics/DavisTbirdEject.jpg You can't really tell here what the flaps are doing. I suspect this is the highest lift configuration the F-16 has in this situation. It still wasn't enough. I know that the leading edge slats were automatic, but not the flaps. There's just something wrong with not being able to manual command a flap extension or retraction. :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft Todo List
There was an otherwise forgettable Strike Fighters game released about a year ago that did contrails really well. You could finish a dogfight and look up to see bright, looping contrail traces of the fight in the sky. I don't know why you'd call it forgettable. There's a huge following that's been making new aircraft and other things for it. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft Todo List
Gene Buckle wrote: Andy Ross wrote: [...] otherwise forgettable Strike Fighters game [...] I don't know why you'd call it forgettable. There's a huge following that's been making new aircraft and other things for it. It's all eye candy, no meat. Pretty aircraft, beutiful cockpits, nice sounds. Awful terrain, laughable flight model. I distinctly remember being very impressed by their 6DOF attitude gyro in the A-4 (something I worked hard at for our version), until I noticed it was turning the WRONG WAY. Ugh. A lot of work has gone into fixing it and people are even making new terrain for it. Since it's classed as a survey sim, it's not going to have high quality flight models like FlightGear does. :) An effect I'd like to see is heat blur at the exhaust end of jet engines along the lines that Lock On: Modern Air Combat has. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aircraft Todo List
+++ Outside: - flaps are in wrong position by default after starting flightgear - flaps can't be triggered This is because flaps are flight computer controlled for the F-16. I suspect that about every (military) aircraft designed after the F-16 does have the same behavior. I have a hard time with the computer controlled flap thing. :) I know that with every jet I've studied, you can manually select the trailing edge flap position. This does not hold true for the leading edge flap though (on those jets that have them). g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft Todo List
Gene Buckle wrote: I have a hard time with the computer controlled flap thing. :) I know that with every jet I've studied, you can manually select the trailing edge flap position. This does not hold true for the leading edge flap though (on those jets that have them). The FC adjusts the flap settings to optimal performance under _all_ circumstances. I have yet to read somewhere there is a flap override for the F-16. Hmmm. I knew there was a reason I didn't like that airplane. :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DOS escape characters
Jon, just use standard ANSI escape sequences. g. On Fri, 9 Apr 2004, Jon S Berndt wrote: Does anyone know how to do escape sequences in a DOS console? I mean, how do you tell the DOS command shell to BOLD or Underline or change the color of text? Jon ___ 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] More on JSBSim ground trimming issue
black box. As such, it is no different than any other piece of code: GIGO. Just for curiosity: What is GIGO? Garbage In, Garbage Out. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] De-glutification, stage one
Roll our own: Probably no one will be interested in this option, but I thought I'd throw it out there just in case. FlightGear is a big enough project now that maintaining our own OS integration layer wouldn't be a terribly large part of the development effort. This would get us maximum flexibility for nifty hacks. An outsider's view: Wouldn't it make sense to roll all these nifty hacks into PLIB so everyone can make use of them or is PLIB too restricted to make this a realistic vision ? From what I've hread about this kind of think in the past, patches submitted to PLib from FlightGear have been totally ignored. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: driving FlightGear from an external app
Arnt Karlsen wrote: .._is_ www.cloudcaptech.org the correct address??? I get nothing ^^^ .com ..thanks. Oo, _neat_ toys. :-) VERY neat toys. I wonder if that Crista IMU could be used to drive a ground based artificial horizon... That would come in very handy when I get to the point where I want to run R/C aircraft from my sim cockpit. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: driving FlightGear from an external app
Arnt Karlsen wrote: .._is_ www.cloudcaptech.org the correct address??? I get nothing ^^^ .com ..thanks. Oo, _neat_ toys. :-) VERY neat toys. I wonder if that Crista IMU could be used to drive a ground based artificial horizon... That would come in very handy when I get to the point where I want to run R/C aircraft from my sim cockpit. ..web camera and an 802.11 link to web site for live footage? ;-) 50Mhz R/C gear and 70cm ATV for the video downlink. The plan is for three cameras (left, right and center) for display on the projector screens the sim uses. Now granted, this is a couple of years down the road. I've got a lot of work yet to do on the sim itself. The eventual goal is to have a camera plane like a 12' Telemaster for doing aerial photo work. I'd like to be able to build a 1:5 scale F-15C for doing airshows, but that's a WAY off. :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal Sockets...
Gene Buckle wrote: Andy, is it possible to make socket calls within a Nasal script? If not, how hard would it be to add that kind of ability? Right now, you can only talk to the rest of FlightGear through the properties tree. Adding the socket stuff probably wouldn't be hard at all; what do you need to do with it? It's not something I particualrly need, it comes from something on another project. I'm working with a commercial game developer to add data exports to their simulator and since they use Lua script (http://www.lua.org) already, they're just going to add Lua functions to access internal state data that can be then be sent to the outside world via a socket add-in called LuaSocket. This got me thinking about how FlightGear uses Nasal and how it could be used similarly to Lua for this task. It would allow for a more flexible system to import and export data to FG than the current xml defined, text-only net interface does now. This could work well if the Nasal script could be executed at a rate of 20Hz or so. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Borland C++BuilderX Personal for $10
--- start --- Accelerate your C++ development with Borland® C++BuilderX Personal, a multiplatform development environment for building high-performance C++ applications. An innovation in C++ development technology, C++BuilderX provides an intuitive visual development environment with built-in integration for multiple code compilers and debuggers (including Borland C++ and the GNU Compiler Collection) that drive increased efficiency and productivity. Unless it's different from the downloaddable version, it does _not_ include any kind of RAD tool. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Borland C++BuilderX Personal for $10
OK. Yes, I've used Delphi and C++ Builder for a while, but haven't upgraded in a few years. The free C++ compiler BC++ 5.5 of course did not come with an IDE. C++Builder (no X) of course comes with RAD functionality out of the box - that's what it is famous for. It's a bit surprising to me that Borland would put the Builder tag on a product that did not have the RAD functionality - that seems misleading and mis-named. The cross-platform IDE might be nice enough by itself I guess, given the support for multiple compilers, and I may try it out just for that. The IDE is very nice and well worth the download. AFAIK it even interoperates with CVS quite well. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Linux machines
Dell doesn't seem to market machines with Linux installed anymore, do they? Can anyone point me to a major manufacturer that does? Actually they do. I just got a Dell 2650 with Redhat 9 on it. However, they may not offer them in the home market. (The 2650 is an SMP machine). g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] My Flight in a B-1B Flight Simulator at Dyess AFB
One question though. I mentioned trying to line up with a fuel tanker and how the delayed movement was throwing me off. My guess is that this behavior was due to slow control surface movements. My question is if JSBSim simulates control surface movement speeds (excluding the flaps which do) or is the control surface deflection always exactly equal to the control input? I think It has more to do with moving multiple tons of steel and aluminum with a tiny little control surface. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: Cockpit Hardware Building (was: Re: [Flightgear-devel]F-16cockpit)
If Curt doesn't mind providing the facility, I like the idea. It would be nice not to be dependant on the facilities offered by people outside of flightgear to an extent. Also I'm going to be asking a lot of dumb question about input in flightgear and I don't want it to be too public ;-) Anyway I joined simpits.org and posted a question: http://199.254.199.21/cgi-bin/ikonboard/ikonboard.cgi?s=f0d84210e7c118094d0d df81f733a2b9;act=ST;f=15;t=1 Al, you might get a better response on the simpits-tech mailing list. I'm going to be integrating FG into my F-15 so we'll end up covering a lot of common ground. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] F-16 cockpit
Al, go take a peek at www.simpits.org g. On Thu, 4 Dec 2003 [EMAIL PROTECTED] wrote: Hi, Very nice piece of kit - but a little costly. I've been toying with the idea of building my own generic single seat cockpit unit. I do MIDI, LCD, Serial and Keyboard interface controllers. Recently I've got hold of some USB chips and have been planning to make some control panels for FlightGear. I'm wondering how many people would be interested in developing some 'open-source' hardware for FlightGear? We have facilities here including precision CNC milling and drilling, circuit board fabrication and welding. I'd be quite happy to do general control panels at a price little over cost or provide the circuit board and chips. I'm not too familar on how FlightGear handles inputs and frankly I don't want to start getting involved in developing software on the 'other' side on the control panel. I think USB would be a good choice of interface as it would allow for flexible configuration over time. My rough ideas for a generic cockpit would be based on a tubular aliminium frame and supporting structure for displays, PC and controls, with optional plywood cladding for the outside. Internally panels would be held with a steel frame supporting structure. My aims are to make the cockpit as simple to build as possible. This should be easier to achieve if taking a generic approach rather than trying to model the cockpit on a actual aircraft. I don't know if this is the right place to be discussing this (is the devel mail-list intended for software development? If so could a hardware development mail-list be set up?). I'd be happy to hear from anyone interested, even if it's only ideas at this point in time. All the best, Al Quoting Jon Berndt [EMAIL PROTECTED]: F-16 cockpit: http://www.aimsworth.com/ Jon -- Project Coordinator JSBSim Flight Dynamics Model http://www.jsbsim.org ___ 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] (OT) Kid's day at work
That's the way Boeing USED to make them. Compare that cockpit to a new 737-800 ... The new cockpits must make pilot's lives pretty boring. Paul Take a peek at the 727 and 737 here. Real analog stuff. :) http://deltasoft.fife.wa.us/BehindTheScenes/ g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
Unfortunately, plib (our scene graph engine) doesn't support multitexturing at this point in life. :-( From what I've read, this isn't the only thing it doesn't support that would make life easier for you guys. Why not just dump it for a scene graph library that does the job you need it to instead of working around the holes in plib? g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
Gene Buckle writes: Unfortunately, plib (our scene graph engine) doesn't support multitexturing at this point in life. :-( From what I've read, this isn't the only thing it doesn't support that would make life easier for you guys. Why not just dump it for a scene graph library that does the job you need it to instead of working around the holes in plib? This is something that has been considered, but it will be a massive amount of work to do this and preserve all the existing functionality. Massive might be slightly overstated, but it probably means tearing everything down and rebuilding it piece by piece. That's a big job, and it is made more complicated if we want to keep the current cvs head runnable. I can imagine this would be a complex undertaking, but wouldn't it be the best solution in the long run? If it would be easier, why not just fork plib and add the features needed without having to wait for patches to be (maybe) accepted and merged in? g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taxiway progress
On 11/25/03 at 6:22 PM Jon Stockill wrote: With mouse control added, and the ability to directly edit the taxiway features I thought I'd have a try at something a bit more complex. I think this proves that Taxidraw is an extremely useful bit of software: http://flightgear.stockill.org.uk/scenery/ That last field is very impressive. I did notice that there are no curved corners in the taxiways like their are in the real thing. Is this on purpose? g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 727 CPT up for grabs..
Check it out: http://www.simpits.org/~geneb/727cpt.html We're talking _dirt_ cheap here. Curt, it's probably local to you - Minnesota U. has it. They really need it gone so you'll get a good deal. It's begging for a FlightGear interface! :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Flying under the bridge
Really? FG crashes? Or just the plane. The latter is known and a feature. ;-) http://baron.me.umn.edu/pipermail/flightgear-devel/2003-August/020119.html Well technically, it's a mis-feature... :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Odd simgear problem...
I'm working on setting up a build envrionment for FG on a different machine. I checked out the .3 branch of SimGear and I get this: [EMAIL PROTECTED] SimGear]$ sudo ./autogen.sh Host info: Linux i686 automake: 1.7.9 (17) Running aclocal Running autoheader /usr/bin/m4: configure.in: No such file or directory ERROR: autoheader didn't create simgear/simgear_config.h.in! [EMAIL PROTECTED] SimGear]$ When I try to prep it to build. Any idea where the configure.in file ran off to? g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Odd simgear problem...
machine. I checked out the .3 branch of SimGear and I get this: [EMAIL PROTECTED] SimGear]$ sudo ./autogen.sh Host info: Linux i686 automake: 1.7.9 (17) Running aclocal Running autoheader /usr/bin/m4: configure.in: No such file or directory ERROR: autoheader didn't create simgear/simgear_config.h.in! [EMAIL PROTECTED] SimGear]$ When I try to prep it to build. Any idea where the configure.in file ran off to? It's moved to configure.ac You need at least the following version: autoconf 2.5 automake 1.6 [EMAIL PROTECTED] geneb]$ automake --version automake (GNU automake) 1.7.9 [EMAIL PROTECTED] geneb]$ autoconf --version autoconf (GNU Autoconf) 2.58 Any other ideas? :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Odd simgear problem...
That was the problem - thanks Erik. g. On Tue, 18 Nov 2003, Erik Hofman wrote: Gene Buckle wrote: You need at least the following version: autoconf 2.5 automake 1.6 [EMAIL PROTECTED] geneb]$ automake --version automake (GNU automake) 1.7.9 [EMAIL PROTECTED] geneb]$ autoconf --version autoconf (GNU Autoconf) 2.58 Any other ideas? :) Does the output of autoheader --version match the output of autoconf --version ? 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] Another SimGear problem...
Any idea what would cause this? [EMAIL PROTECTED] SimGear]$ ./autogen.sh Host info: Linux i686 automake: 1.7.9 (17) Running aclocal Running autoheader Running automake --add-missing configure.ac:13: version mismatch. This is Automake 1.7.9, configure.ac:13: but the definition used by this AM_INIT_AUTOMAKE configure.ac:13: comes from Automake 1.4-p6. You should recreate configure.ac:13: aclocal.m4 with aclocal and run automake again. /usr/local/share/automake-1.7/am/depend2.am: am__fastdepCXX does not appear in A M_CONDITIONAL /usr/local/share/automake-1.7/am/depend2.am: AMDEP does not appear in AM_CONDITI ONAL The SimGear archive was _just_ checked out from the 0.3 branch. I think I still may have a automake/autoconf problem but I'm not sure. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Speed of jpg-httpd / Another FlightGear movie)
Any ideas? You can try upping the speed with set_hz() initialized in FlightGear\src\Network\jpg-httpd.cxx What you might want to do is use FRAPS. It has a free downloadable demo and is unfortunately Windows only, but it will do exactly what you want. The main site is http://www.fraps.com g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Electrical system work..
Seeing how the ampere draw and the voltage would under normal conditions hardly move (except maybe at start). The information could be programmed into the electrical supply system.I assume we are dealing with light A/C here as I doubt anyone flying a 737 would see an amp metre in their life time.If we are talking about failures then would they not be better handled by a random event generator.After all I guess you are going to have a random event generator tell you the instrument is drawing excess current and then pop the C/B.Why not just tell the elecrical system to pop the circuit breaker. To be able to have circuit breakers pop automatically (lower priority). Once again random event generator To be able to have things start on fire when they are really overloaded (really low priority.) And again random event generator. If you're so stuck on random event generators, go use MSFS. It's full of 'em, including the flight model. The idea here is to be able to create an accurate representation of an aircraft electrical system. To be able to do this accurately, building blocks like circuit breakers are required. The model that Curt and I have been hashing back and forth is actually quite straightforward and easy to use. Terminal Reality used a similar method for their electrical systems in Fly! II, but they went so far as to identify individual wires. We're not getting that detailed. (Yet! *laughs*) Every commercial simulator I've worked with has had some kind of electrical system simulation running. Only video games use random event generators in lieu of proper systems. FlightGear is a _simulator_ first and foremost. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Electrical system work..
.Gene Buckle wrote: Avionics power ratings are always available as nominal and max normal draw. Electrical systems are designed with a bit of extra capacity to deal with power on rush current, etc. The only time an aircraft author would have to give the the current draw any thought at all is if they're also building special avionics and even then, they only really need to specify the nominal draw. The only time the breakers will pop is either on command from an instructor station or via a random systems failure routine. But then there is no need to define amperage in the instruments, is there? Yes there is. That's where the load definition belongs. The load figure should follow the equipment, not the bus it's connected to. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Weight Balance data...
After looking through the various instrumentation files, I noticed that there is no weight data associated with the instruments. For those that don't know, each instrument that goes into the panel is labeled with its weight. This is done to make sure that an accurate dry weight can be calculated. Is there any interest in getting that detailed on the WB calcs? When duplicating a real-world instrument, the weights are easily available and a generic weight could be assigned to avionics that don't model a specific real world model/brand. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Weight Balance data...
Is there any interest in getting that detailed on the WB calcs? When duplicating a real-world instrument, the weights are easily available and a generic weight could be assigned to avionics that don't model a specific real world model/brand. The only problem with that I think is that it won't do much good unless the entire aircraft is itemized, and most of the components' weights won't be known or knowable. I don't think it would buy us anything in noticable dynamic effects. Thanks Jon. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] a FIXME in fg_props.cxx
* [EMAIL PROTECTED] (Gene Buckle) [2003.11.12 10:35]:
code:
static const char *
getDateString ()
{
static char buf[64]; // FIXME
struct tm * t = globals-get_time_params()-getGmt();
sprintf(buf, %.4d-%.2d-%.2dT%.2d:%.2d:%.2d,
t-tm_year + 1900, t-tm_mon + 1, t-tm_mday,
t-tm_hour, t-tm_min, t-tm_sec);
return buf;
}
Why the FIXME in the declaration of buf? Is there a better way of doing
that? Is there a buffer overrun concern or something?
We should at least be using snprintf() here.
So what makes snprintf() a better choice than sprintf()?
snprintf(buf, buflen, format, ...) will not write more than buflen
characters (including the trailing '\0') - this protects you against
a possible buffer overflow . . .
It probably isn't necessary in this case, but it's a Good Habit To
Get Into(tm).
Thanks Simon.
g.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer RFC -- wire protocol spec -- preliminary
Unless there are objections, byte order is little endian, and floats are intel FPU standard (ok -- i'm making it easy on the PCs that will likely be used to run display clients :) Is there any specific reason not to use human readable messages (i.e., ASCII)? It's a waste of bandwidth. The volume of data is immense and you want to make your data packets as efficent as possible. The smaller you can make your data, the less chance there is of warping, teleporting, etc. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Electrical system work..
This would be the easy way to supply the data. However, I think it might be better if the power draw figure was part of the instrument definition itself. This would require 2 new tags added to the xml files that are used to define each instrument - I'm referring to the configurationd data found in data/Aircraft/Instruments. This sounds like a good idea, but I expect that the lack of good information spoiled the idea. One might be able to get the power consumption by a device, but often the peak power consumption is much higher. And it's the peak power consumption that causes circuit breakers to pop out. I could imagine that certain actions can cause circuit breakers to pop most of the time on some aircraft, but defining the power consumption based on specific actions might be a little to much to ask for aircraft developers. Avionics power ratings are always available as nominal and max normal draw. Electrical systems are designed with a bit of extra capacity to deal with power on rush current, etc. The only time an aircraft author would have to give the the current draw any thought at all is if they're also building special avionics and even then, they only really need to specify the nominal draw. The only time the breakers will pop is either on command from an instructor station or via a random systems failure routine. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......
(if its just the one plane, once I get it to fly multiplayer, my focus will be to add multiple/AI plane support to the code, so comments towards achieving that goal will be welcome also) I think it would make sense to have the server handle any non-human controlled vehicles. It would keep the load off the client which already has its hands full doing a full systems simulation as well as doing graphics work. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Missing files or old docs?
in ..src/Main/README: fgfs.cxx fgfs.hxx This module defines FGSubsystem, the abstract base class (or interface) for subsystems in FlightGear. Most of the important subsystems already extend this class, and eventually, all subsystems will. Have these files been removed or did they go missing? I've been trying to find the shutdown portion of the main loop so that I might try to resolve the question posed in fg_props.hxx: extern void fgInitProps ();// fixme: how are they untied? A grep -R shows me that none of the properties that are tied in fgInitPorps() are untied. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Electrical system work..
In part of my learning the ins and outs of how FG really works, I found another space I can contribute - the electrical system. The current system has no way of handling circuit breakers or measuring a load across a whole bus. The system now expresses a bus like this: bus name.../name prop/systems/electrical/outputs/device/prop prop/systems/electrical/outputs/device2/prop . . . /bus What I propose is something like this: bus name.../name circuit name.../name capacitycapacity_in_amps/capacity prop/systems/electrical/outputs/device/prop prop/systems/electrical/outputs/device2/prop . . . /circuit /bus At this point, the bus can be organized into multiple breaker protected circuits on a single bus. The only part of missing data is the Ampere draw of each device. This could be done within the electrical system definition like this: prop/systems/electrical/outputs/device load=n.n/prop This would be the easy way to supply the data. However, I think it might be better if the power draw figure was part of the instrument definition itself. This would require 2 new tags added to the xml files that are used to define each instrument - I'm referring to the configurationd data found in data/Aircraft/Instruments. The first tag would be device-class. This would be something like nav-radio or avionics-fan. It would be used by the load calculator to locate the load value associated with a particular device. The second tag would be load or power-draw or something similar. It would be a double value containing the total draw for the device. When the load calculator comes by, this is the number that gets added to the total (obviously). The idea is to allow custom devices to hold their own power draw values independant of the wiring. For instance, you could change out the stock nav radio for some fancy unit that combines more than one function but has a higher power draw. The device would still be of the class nav-radio but would contain an updated power draw figure. The change would only occur within the instrument panel file and would make sure that no matter the unit installed, the power draw value would follow the device and not the wiring harness. The circuit load would be calculated each time the electrical system's update method is called. If the total load exceeds the circuit capacity for longer than 2 seconds, the breaker would pop and power for that circuit would be cut off. If this is something that you think should be implemented, let me know and I'll start working on the code for it. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Missing files or old docs?
Gene Buckle wrote: in ..src/Main/README: fgfs.cxx fgfs.hxx This module defines FGSubsystem, the abstract base class (or interface) for subsystems in FlightGear. Most of the important subsystems already extend this class, and eventually, all subsystems will. Have these files been removed or did they go missing? They moved over to SimGear/simgear/structure/subsystem.[ch]xx Thanks Erik. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] a FIXME in fg_props.cxx
On Wed, 12 Nov 2003, Cameron Moore wrote:
* [EMAIL PROTECTED] (Gene Buckle) [2003.11.12 10:35]:
code:
static const char *
getDateString ()
{
static char buf[64]; // FIXME
struct tm * t = globals-get_time_params()-getGmt();
sprintf(buf, %.4d-%.2d-%.2dT%.2d:%.2d:%.2d,
t-tm_year + 1900, t-tm_mon + 1, t-tm_mday,
t-tm_hour, t-tm_min, t-tm_sec);
return buf;
}
Why the FIXME in the declaration of buf? Is there a better way of doing
that? Is there a buffer overrun concern or something?
We should at least be using snprintf() here.
So what makes snprintf() a better choice than sprintf()?
g.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Well I feel like a total idiot right now. Everything I'm thinking about that needs to be done has already had the core done. *slaps forehead* The entire groundwork has been laid by the contents of the src/Network directory. The work done for OpenGC stands as a great example of building an external plug-in. I suspect that generic.cxx defines a method of building an interface via an XML configuration file, but I need to study (and understand!) it further. Is there anything that uses this generic interface? I'd like to see an example of the XML it reads if possible.. There is a configuration file in FlightGear/data/Protocol/ At this moment it is an ASCII output protocol only implementation but it wouldn't bee too hard to add input support also. Thanks Erik. I'll take a look at it tonight when I get home. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Building Mesa...
In trying to build plib, it tells me I need glut. No biggie, right? Mesa has that so I'll just build it. I downloaded v5.0.2 and after ./configure, I try making. It explodes instantly with: [EMAIL PROTECTED] Mesa-5.0.2]$ make cd . /bin/sh ./config.status conf.h config.status: creating conf.h config.status: conf.h is unchanged make all-recursive make[1]: Entering directory `/home/geneb/Mesa-5.0.2' Making all in include make[2]: Entering directory `/home/geneb/Mesa-5.0.2/include' Making all in GL make[3]: Entering directory `/home/geneb/Mesa-5.0.2/include/GL' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/geneb/Mesa-5.0.2/include/GL' make[3]: Entering directory `/home/geneb/Mesa-5.0.2/include' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/home/geneb/Mesa-5.0.2/include' make[2]: Leaving directory `/home/geneb/Mesa-5.0.2/include' Making all in src make[2]: Entering directory `/home/geneb/Mesa-5.0.2/src' Making all in math make[3]: Entering directory `/home/geneb/Mesa-5.0.2/src/math' /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -I../../src-g -O2 -Wall -fomit-frame-pointer -ffast-math -fexpensive-optimizations -fstrict-aliasing -malign-loops=2 -malign-jumps=2 -malign-functions=2 -D_REENTRANT -DPTHREADS -c -o m_debug_clip.lo `test -f 'm_debug_clip.c' || echo './'`m_debug_clip.c ../../libtool: s%^.*/%%: No such file or directory ../../libtool: -e: command not found ../../libtool: -e: command not found ../../libtool: -e: command not found ../../libtool: -e: command not found ../../libtool: -e: command not found ../../libtool: -e: command not found ../../libtool: -e: command not found ../../libtool: -e: command not found ../../libtool: -e: command not found ../../libtool: -e: command not found ../../libtool: -e: command not found ../../libtool: -e: command not found ../../libtool: -e: command not found ../../libtool: -e: command not found ../../libtool: -e: command not found ../../libtool: -e: command not found ../../libtool: -e: command not found ../../libtool: -e: command not found ../../libtool: -e: command not found ../../libtool: -e: command not found ../../libtool: -e: command not found ../../libtool: -e: command not found : compile: cannot determine name of library object from `' make[3]: *** [m_debug_clip.lo] Error 1 make[3]: Leaving directory `/home/geneb/Mesa-5.0.2/src/math' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/geneb/Mesa-5.0.2/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/geneb/Mesa-5.0.2' make: *** [all] Error 2 My libtool version is 1.4.2, automake is 1.7.8 and autoconf is 2.58. Ideas? I ran configure with the --prefix=/usr parameter per the Mesa install doc. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Building Mesa...
./configure, I try making. It explodes instantly with: ../../libtool: s%^.*/%%: No such file or directory No need for harsh language one would say :-) Maybe you could try freeglut instead: http://freeglut.sourceforge.net/fg/ Thanks for the tip Eric. However, it explodes with: [EMAIL PROTECTED] freeglut-2.0.1]$ make make all-recursive make[1]: Entering directory `/home/geneb/freeglut-2.0.1' Making all in src make[2]: Entering directory `/home/geneb/freeglut-2.0.1/src' source='freeglut_callbacks.c' object='libglut_la-freeglut_callbacks.lo' libtool=yes \ depfile='.deps/libglut_la-freeglut_callbacks.Plo' tmpdepfile='.deps/libglut_la-freeglut_callbacks.TPlo' \ depmode=gcc3 /bin/sh ../depcomp \ /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/X11R6/include -g -O2 -c -o libglut_la-freeglut_callbacks.lo `test -f freeglut_callbacks.c || echo './'`freeglut_callbacks.c rm -f .libs/libglut_la-freeglut_callbacks.lo gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/X11R6/include -g -O2 -c freeglut_callbacks.c -MT libglut_la-freeglut_callbacks.lo -MD -MP -MF .deps/libglut_la-freeglut_callbacks.TPlo -fPIC -DPIC -o .libs/libglut_la-freeglut_callbacks.lo In file included from ../include/GL/freeglut.h:17, from freeglut_callbacks.c:34: ../include/GL/glut.h:85:20: GL/glu.h: No such file or directory In file included from freeglut_callbacks.c:35: freeglut_internal.h:72:20: GL/glu.h: No such file or directory make[2]: *** [libglut_la-freeglut_callbacks.lo] Error 1 make[2]: Leaving directory `/home/geneb/freeglut-2.0.1/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/geneb/freeglut-2.0.1' make: *** [all] Error 2 [EMAIL PROTECTED] freeglut-2.0.1]$ Any idea where I can find glu.h? :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Building Mesa...
On 11 Nov 2003, Martin Spott wrote: Gene Buckle [EMAIL PROTECTED] wrote: In trying to build plib, it tells me I need glut. No biggie, right? Mesa has that so I'll just build it. I downloaded v5.0.2 and after ./configure, I try making. It explodes instantly with: Sorry, never built Mesa from scratch. In case you don't mind you could simply install Mesa and GLUT from your favorite distribution - from the output you've posted I assume you're running some Linux. If you really only need the GLUT library on something else than Linux I'd suggest to build FreeGLUT - that one works on most Unix-like platforms, I tried building FreeGLUT per Erik's suggestion, but as you can see from my reply to him, it blows up due to a missing header file. I don't even want to run FG on the machine I'm building it on, I just want to make sure I can get a clean compile. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Patch format..
What is the accepted format for submitting patches? Is a diff used? If so, what command line is recommended for it? Tnx. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Building Mesa...
Erik Hofman writes: Gene Buckle wrote: Any idea where I can find glu.h? :) That one should be part of an opengl-dev package. On my system, glu.h comes from the glut-dev package. (sorry Gene) :-) Ok, where can I get glut-dev? g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch format..
I admit to being slightly patch impaired and have had it blow up on
me more times than I've had it work cleanly. In addition, I like to
review the submitted changes before I apply them, and I like to do
that with emacs-ediff mode. Because of the way I prefer to do things,
it's easiest and most convenient for me to receive whole copies of any
files that are changed, rather than just the patches. Other people do
things differently and prefer just the patches. I'd recommend using
diff -c if you plan to submit just the patches. That gives a bit of
context around each patch so the patch utility can tell if the
underlying file has changed and fail gracefully rather than blindly
applying a diff in the (now) wrong place.
Ok. I did a bit of digging after asking the question and found a
recommended command:
cvs diff -c3p
This gives this style result:
Index: controls.hxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Controls/controls.hxx,v
retrieving revision 1.6
diff -c -3 -p -r1.6 controls.hxx
*** controls.hxx24 Sep 2003 17:20:56 - 1.6
--- controls.hxx11 Nov 2003 18:26:42 -
*** public:
*** 86,91
--- 86,96
MAX_AUTOPILOTS = 3
};
+ enum {
+ ALL_ESEATS = -1,
+ MAX_ESEATS = 10
+ };
+
private:
// controls/flight/
double aileron;
Is this acceptable?
g.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Building Mesa...
Ok, where can I get glut-dev? If you are on a linux system, there is a good chance your distribution has this prepackaged in a package called glut-dev or glut-devel or something very similar. If you are using cygwin, there is a good chance it includes glu.h in one of it's packages. If you are on some other platform, I don't know. What is used to generate glut-dev? It has to come from somewhere g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Building Mesa...
Nonetheless, it's actually not hard to compile by hand. If I didn't goof up the line endings below, you should be able to get into the src-glut directory and paste the following two commands: There is no src-glut directory. src-glu is the closest. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Building Mesa...
Gene Buckle wrote: Andy Ross wrote: Nonetheless, it's actually not hard to compile by hand. If I didn't goof up the line endings below, you should be able to get into the src-glut directory and paste the following two commands: There is no src-glut directory. src-glu is the closest. Glut is in the MesaDemos package. If you downloaded MesaLib only, you'll need this one too. The GLU library is an entirely different beast. :) Well doesn't that just figure. *sigh* g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Building Mesa...
in a static library. This is *definitely* the right way to go if you're installing something that might be replaced by your distribution's official copy later on. Just drop the resulting libglut.a file into /usr/local/lib*, and the glut.h from the include/GL directory into /usr/local/include/GL, and you're done. As always, my preference is to use a custom prefix for builds rather than /usr/local. But this is where the plib/SimGear/FlightGear builds will look by default. FYI, the ./configure method of building Mesa 5.0.2 seems totally broken. I'm currently building using the old method and it's going ok. (crap, it just blew up on the link phase...*pounds head on desk*) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Building Mesa...
this is a bug in libtool. you need to do 'export SED=/bin/sed' (or 'setenv SED /bin/sed' depending on your shell) before building. Thanks Alex. Almost got it: mkdir .libs rm -fr .libs/libMesaAC.la .libs/libMesaAC.* .libs/libMesaAC.* ar cru .libs/libMesaAC.al ac_context.lo ac_import.lo ranlib .libs/libMesaAC.al creating libMesaAC.la (cd .libs rm -f libMesaAC.la ln -s ../libMesaAC.la libMesaAC.la) make[3]: Leaving directory `/home/geneb/Mesa-5.0.2/src/array_cache' Making all in X86 make[3]: Entering directory `/home/geneb/Mesa-5.0.2/src/X86' Makefile:358: *** missing separator. Stop. make[3]: Leaving directory `/home/geneb/Mesa-5.0.2/src/X86' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/geneb/Mesa-5.0.2/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/geneb/Mesa-5.0.2' make: *** [all] Error 2 [EMAIL PROTECTED] Mesa-5.0.2]$ Didn't they test the damn thing before they released it? This is so frustrating all I want to do is take a baseball bat to the packager... Any ideas? g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FAQ suggestion.
I think we need to add something like the following to the FAQ: Please read section #2.2 and #2.3 of the FAQ before emailing Curt about FTP problems. I'm not sure if that get's too recursive, and it probably wouldn't do any good. sigh How about : A compileable version of GLUT can be found at x ...as well? g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FAQ suggestion.
How about : A compileable version of GLUT can be found at x ...as well? You guys have to help me out here. Send me the question and answer, and I will add it to the FAQ. Thanks Mesa 5.0.2 fits the bill as long as the MesaDemo source archive is downloaded and built as well. The configure script is terminally broken. It does _not_ work at all. To build use: cp Makefile.X11 Makefile make clean make make linux// or another config from the list. This is per Brian Paul (author of Mesa) in a posting to the mesa3d-users list. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Building Mesa...
Gene Buckle [EMAIL PROTECTED] wrote: I tried building FreeGLUT per Erik's suggestion, but as you can see from my reply to him, it blows up due to a missing header file. Hmmm, I build FreeGLUT on Linux and on Solaris at the time when they headed for a 2.0 release (they even fixed a Solaris-related bug for me). I had excellent expérences with libfreeglut as a drop-in- replacement for FlightGear. You might want to try a 2.0 release, Thanks Martin. I've got Mesa sorted out and built. It would have been nice had the author made a note of the problem - especially since a) it's not fixed and b) has been present since the 5.0.2 release in September. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] My first real patches...
Basically what I've done here is expanded upon the ejection seat
properties to make them more flexible.
I did this as a patch because it was something that a) needed to be done
and b) looked simple enough for me to do without botching it too badly. :)
The former property node was:
/controls/seat/eject as a boolean value.
Since there are a number of ejection seat equipped aircraft out there that
have more than one seat, I've added code to track those.
The tree now looks like this:
/controls/seat/eject[%d]/initiate - bool
If this becomes true, then the handles were pulled.
/controls/seat/eject[%d]/status - int
This describes the current status of each seat.
SEAT_SAFED - seat won't fire if handles are pulled (no code behind this
yet)
SEAT_ARMED - the safety pins have been removed and the seat CAN be fired.
SEAT_FAIL - initiator train has failed or instructor forced the seat not
to operate.
/controls/seat/cmd_selector_valve - int
This holds the position of the Command Selector Valve that is used
to control how 2 seat ejection functions.
CMD_SEL_NORM - Rear seat fires and then front seat fires if front seat
fires. If the rear seat is fired, it does not initiate the front seat.
CMD_SEL_AFT - Rear seat fires first when triggered from either seat.
CMD_SEL_SOLO - Front seat fires and then rear seat after a small delay.
There's more technically descriptive detail about how the whole system is
supposed to work, but for a basic first pass this should suffice.
Note that the only real functionality is in the handling of the seat
status condition when a seat is fired. No other programming has been
done as yet. However, if someone adds a bang seat to one of the models,
I'd be happy to get the routines fleshed out more.
Questions? Comments? What'd I forget?
Thanks.
g.
Index: README.properties
===
RCS file: /var/cvs/FlightGear-0.9/source/docs-mini/README.properties,v
retrieving revision 1.2
diff -c -3 -p -r1.2 README.properties
*** README.properties 1 Apr 2003 18:58:46 - 1.2
--- README.properties 11 Nov 2003 23:41:30 -
*** Seat
*** 119,125
/controls/seat/vertical-adjust
/controls/seat/fore-aft-adjust
! /controls/seat/eject
APU
---
--- 119,127
/controls/seat/vertical-adjust
/controls/seat/fore-aft-adjust
! /controls/seat/cmd_selector_valve
! /controls/seat/eject[%d]/initiate
! /controls/seat/eject[%d]/status
APU
---
Index: controls.hxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Controls/controls.hxx,v
retrieving revision 1.6
diff -c -3 -p -r1.6 controls.hxx
*** controls.hxx24 Sep 2003 17:20:56 - 1.6
--- controls.hxx11 Nov 2003 23:36:19 -
*** public:
*** 86,91
--- 86,108
MAX_AUTOPILOTS = 3
};
+ enum {
+ ALL_EJECTION_SEATS = -1,
+ MAX_EJECTION_SEATS = 10
+ };
+
+ enum {
+ SEAT_SAFED = -1,
+ SEAT_ARMED = 0,
+ SEAT_FAIL = 1
+ };
+
+ enum {
+ CMD_SEL_NORM = -1,
+ CMD_SEL_AFT = 0,
+ CMD_SEL_SOLO = 1
+ };
+
private:
// controls/flight/
double aileron;
*** private:
*** 211,219
// controls/seat/
double vertical_adjust;
double fore_aft_adjust;
! bool eject;
!
! // controls/APU/
int off_start_run;
bool APU_fire_switch;
--- 228,238
// controls/seat/
double vertical_adjust;
double fore_aft_adjust;
! bool eject[MAX_EJECTION_SEATS];
! int status[MAX_EJECTION_SEATS];
! int cmd_selector_valve;
!
! // controls/APU/
int off_start_run;
bool APU_fire_switch;
*** public:
*** 394,400
// controls/seat/
inline double get_vertical_adjust() const { return vertical_adjust; }
inline double get_fore_aft_adjust() const { return fore_aft_adjust; }
! inline bool get_eject() const { return eject; }
// controls/APU/
inline int get_off_start_run() const { return off_start_run; }
--- 413,422
// controls/seat/
inline double get_vertical_adjust() const { return vertical_adjust; }
inline double get_fore_aft_adjust() const { return fore_aft_adjust; }
! inline bool get_ejection_seat(int which_seat) const { return eject[which_seat]; }
! inline int get_eseat_status(int which_seat) const { return status[which_seat]; }
! inline int get_cmd_selector_valve() const { return cmd_selector_valve; }
!
// controls/APU/
inline int get_off_start_run() const { return off_start_run; }
*** public:
*** 571,577
void move_vertical_adjust( double amt );
void set_fore_aft_adjust( double pos );
void move_fore_aft_adjust( double amt );
! void set_eject( bool val );
// controls/APU/
void set_off_start_run( int pos );
Re: [Flightgear-devel] My first real patches...
FDM for a parachute ?? round or rectangular chute ?? joystick controls the shrouds ?? cutting loose the main and deploying the spare ?? skydiving ?? (ok -- not really related to the ejection code itself, but it would be nice :) ) In those cases, would be nice == way over my head. :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FAQ suggestion.
Mesa 5.0.2 fits the bill as long as the MesaDemo source archive is downloaded and built as well. The configure script is terminally broken. It does _not_ work at all. To build use: cp Makefile.X11 Makefile make clean make make linux// or another config from the list. This is per Brian Paul (author of Mesa) in a posting to the mesa3d-users list. g. Ok...uh, what was the question? :-) I haven't been following the Mesa discussions. Where can I find/build/obtain/fold/spindle/mutilate GLUT? g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status
it offensive to even have source code included that discusses in weapon terms, To me this is absurd to the extreme. To you maybe. This may not be the proper forum for you to be asserting judgements like that anyway (see alt.politics.*) :-D ...with cross-posts to alt.save.da.fwuffy.bunny and alt.wesley.crusher.die.die.die. :) And in case someone didn't read my earlier post, I do not hold this opinion myself, but I do think that a topical RFC should be posted before any war related code is committed, even with a configuration flag. This _is_ a hot button whether anyone thinks it should be or not. I read the whole post. Really! :) I guess my problem is that I'm totally unable to understand why someone would object to just the _presense_ of munitions code even being present. It completely baffles me. Even as I sit here pondering the why, all I can come up with is pejorative commentary and that's unfortunate. BTW, I know a group of virtual F-16 drivers that would practically wet themselves over software they could use to drive their cockpits with. :) Falcon 4.0 doesn't go far enough with their data exports. g. -- Proud owner of 80-0007 http://www.f15sim.com - The only one if its kind. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
On Monday, 10 November 2003 21:14, Gene Buckle wrote: BTW, I know a group of virtual F-16 drivers that would practically wet themselves over software they could use to drive their cockpits with. :) Falcon 4.0 doesn't go far enough with their data exports. I like the idea of FlightGear being able to support military type stuff but where do we draw the line? If there is too much military specific code hooking into core parts of FG then it could get messy and even slow things down both framerate wise and development wise. Understood. The only feature that I can think of that cannot be an external plug-in is collision detection. There are so many things that are specific to aircraft like the F16 that require more than just an instrument display. For instance ground radar and FLIR systems. Being able to acquire and lock onto ground targets has nothing to do with general aviation but is absolutely necessary for military simulations. That means there would have to be an interface between the panel system and terrain rendering system. This can be made a plug-in that uses the same terrain data that FG is using. All the code that is the FLIR (or LANTIRN, or LITENING II, etc) could (and should!) be implemented as an external plug in. If it's executing on the same host as the simulation, it would need write permission to the main frame buffer to allow its display to be shown. This same method could apply to a glass flight director or ADI, engine displays, etc. A plug-in system like that would be a universal technology that could be applied to both military and civilian/commercial systems. We could also add some sort of online, persistent, dynamic, war engine for multiplayer missions. *eyes glaze over* Oooh. *wistful sigh* One could go a step further and reason that FlightGear should support space simulation as well. (probably not that hard considering that FG simulates the celestial bodies pretty well) Take that far enough and we'll soon have lunar rovers and ... and ... and ... YES! What is the chief goal/aim of FG? I thought it was trying to simulate just general and commercial aviation. However having said that I would love an F16 multiplayer simulation. :) BUT not at the expense of general aviation. Of course not. The two genres can live together quite well as long as there are not any squabbling about the glue points between the two worlds. Anyone know of a good C++ tutorial? :) Something tells me I'm gonna need it. *g* g. -- Proud owner of 80-0007 http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Hey Gene since I am the one who initially brought up the issue I guess you are the one responsible for my ears burning :-) Wasn't me. I'd chase down the guy with the matches. :) What I *was* objecting to and *will* continue to object to is a 'primary goal' of 'blow them out of the sky' and any attempts at turning the goal of FGFS into such !! We both agree on this. My only concern is the blocking of shared technologies from the source repository simply because it's used by other portions to support combat features that are not practically implementable as a plug-in. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
I think a dynamic shared library system that lets an a/c load up a module of its particular code when it is loaded needs to be added to the system -- be a nice place to stick information unique to that plane that is dynamic in nature -- can handle specialized panel displays, hud, etc In that case, some kind of framework should be built so that the plug-in could run on a seperate machine if needed. Give me a LITTLE time to get the basics online :) (Or a persistent dynamic civilian world -- hehehe read in airline flight schedules daily) Persistant world period. The benefits would be just too phenomenal to think about, especially from the just-wanna-have-fun user end of this thing. Here's a scenario for ya: User connects up, and picks where they want to fly from and what class of aircraft they want to fly. They're then deposited in the FBO, terminal building or AFB hangar on the field they're going to fly from. They could then pick what they wanted to fly by menu, _or_ by walking outside and picking the plane they wanted from a selection of them parked on the ramp. All the while seeing AI and real traffic above them and other users wandering around on the ground with them. Makes me all squishy-headed just thinking about the possibilities. *sigh* MORE MORE MORE :) NOW NOW NOW! :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Anyone know of a good C++ tutorial? :) Something tells me I'm gonna need it. *g* Not sure if you're just kidding or serious ... There's plenty of free C++ info online but here are a couple of free books : Thanks Paul. I pay my mortage with Delphi, VB Pick. My C/C++ skills are just enough to be able to identify it on sight and begin running the other way. :) http://cpp-home.com/tutorials/ excellent tutorials for n00bs to pro This looks like what I'm after. Thanks! I'm not a very good C++ programmer and I keep forgetting stuff so I'm forever referring back to my library of downloaded tutorials, books, etc. Maybe I'm not the only one. :) Do you know of a small paper quick reference that's any good? g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Thanks Paul. I pay my mortage with Delphi, VB Pick. My C/C++ skills are just enough to be able to identify it on sight and begin running the other way. :) Sounds like you need a varient of the following t-shirt (credit to Mark Barry.) http://www.markbarry.com/pictures/bombtech.jpg Yep, pretty much. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
I also come from a Delphi background but find the switch very easy. Great! I'll help you write the server in Delphi. We can cross compile with FPC. *laughs* Why does C++ scare you? Well scare is probably too strong a word. :) I'm just unfamiliar with it. I can follow C ok, but the object references tangle me for some odd reason. The last time I tried getting my feet wet in code here got me bitched out by the plib author for basically not doing something his way. Instead of giving him precise and graphic instructions about what he could do with his way, I dropped it and walked away. These days I'd be just as likely to have verbally shot his high horse out from under him and beat him stupid with the corpse. :) I never have taken well to unhelpful criticism(sp!) Do you know of a small paper quick reference that's any good? A reference for the C++ language syntax or for C++ libraries? Just a syntax ref would be nice. O'Reilly makes a neat one for PHP but I don't know about any C++ offering they have. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
a nice place to stick information unique to that plane that is dynamic in nature -- can handle specialized panel displays, hud, etc In that case, some kind of framework should be built so that the plug-in could run on a seperate machine if needed. um ?? for code/data local to an a/c instance ?? remoting that would slow down the response time to realtime events For virtual cockpits, you're correct. however, when you're working with a physical cockpit, you need to have your displays on separate physical hardware. If the simulation reacts within 150ms of the real thing, you're still good for Class D anyway. 150ms is an eternity for most computers. Even on a 10BaseT network you should be ok. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] C++ question...
I see code like this: limit_value (double * value, const SGPropertyNode * arg) .and wonder about the placement of the pointer operator. I would think the above would be functionally different than: limit_value (double *value, const SGPropertyNode *arg) I think of the multiplication operator when I see whitespace after the *, but I know(for small values of know) that if it were really parsed as trying to multiply a variable by a variable type, the parser would throw a fit. Why the extra whitespace in the declaration? g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C++ question...
Thanks for the clue Paul. :) g. On Tue, 11 Nov 2003, Paul Surgeon wrote: On Tuesday, 11 November 2003 00:47, Gene Buckle wrote: I see code like this: limit_value (double * value, const SGPropertyNode * arg) .and wonder about the placement of the pointer operator. C syntax : type *p C++ syntax : type* p The compiler doesn't care which you use. They both mean the same thing. Why the extra whitespace in the declaration? Cause some developer felt like coding that way. (I don't like his/her style but it's still valid) The compiler knows that it's not multiplication because it is a type declaration. Remove the type and it would mean multiplication. The same rule applies to multiplying integer/floating point variables. a* b = a *b = a * b The compiler knows the difference between variables and types. Paul ___ 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] Multiplayer Server RFC -- Current Status
um ?? for code/data local to an a/c instance ?? remoting that would slow down the response time to realtime events For virtual cockpits, you're correct. however, when you're working with a physical cockpit, you need to have your displays on separate physical hardware. If the simulation reacts within 150ms of the real thing, you're still good for Class D anyway. 150ms is an eternity for most computers. Even on a 10BaseT network you should be ok whoa whoa whoa !!! thats more slaving the kb/mouse/stick inputs to an exterernal source, and feeding out info that would normally drive the panel/hud -- arent there native_ctrls/native_fdm/native_gui that handle that ?? (though I would be much happier seeing that handled completely seperate from any network multiplayer -- i.e. a plugin cockpit i/o module, as you could have a physical cockpit sim driven by FG hooked into a network multiplayer server) I'm just getting back into rooting around in the code and I don't yet have a solid grasp on all the parts. AFAIK, the only native support for an external module is OpenGC from what I've seen so far. I was referring the creation of a universal method of obtaining data from the sim via network - but only if such a mechanism doesn't already exist. If it does, point me to it and I'll go away. :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C++ question...
Personally I prefer
int* ip;
That would turn me into a gibbering idiot. :)
Kernighan and Richie specifically say in The C Programming Language though
that they like to write
int *ip;
since it reinforces the point that dereferencing ip (*ip) gives an int.
Now THAT makes sense. You have to understand though, the last time I
wrote anything serious in C, the only way to define functions was this:
main(argc, argv)
int *argc;
char **argv;
{
}
...note that it's been *years* since I had more than a passing
accquaintance(sp) with main() so I probably got the parameters
backwards...
g.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
I'm just getting back into rooting around in the code and I don't yet have a solid grasp on all the parts. AFAIK, the only native support for an external module is OpenGC from what I've seen so far. I was referring the creation of a universal method of obtaining data from the sim via network - but only if such a mechanism doesn't already exist. If it does, point me to it and I'll go away. :) I'm only guestimating based on the filenames :) Well I feel like a total idiot right now. Everything I'm thinking about that needs to be done has already had the core done. *slaps forehead* The entire groundwork has been laid by the contents of the src/Network directory. The work done for OpenGC stands as a great example of building an external plug-in. I suspect that generic.cxx defines a method of building an interface via an XML configuration file, but I need to study (and understand!) it further. Is there anything that uses this generic interface? I'd like to see an example of the XML it reads if possible... I think that for non-visual systems, you could have sub-assembly programs running that all talk to FG via the already present network layer. Since it's basically localhost stuff, it should be as fast as it would ever need to be. Is that a valid assumption? Now -- how much does one of these physical cockpits cost ?? I want one for the basement :) The correct answer is How much you got? :) In all seriousness, you can spend as little or as much as you'd like. A first place to stop is http://www.simpits.org and join the mailing list. We're always happy to see a new vic^H^H^Hhobbiest join our little group. There are examples from my F-15C, to scratch build F-16s and a home-made 777. A recent discussion on rivets was started by pics of a new guys' Vultee Vulture, a fictious WWII era airplane named for the Vultee logo that is on the rudder pedals he's using. (The seat came out of a BT-13) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status [now C++]
If you start a project and need OO features, either do it properly (in Python or Objective-C), or do it the hard way with GLib/GObject. Naw, Object Pascal is my first love. :) I'd better shut up on the mailing list of a giant project written in C++... I still admire you folks for getting it this far even with C++! Well look at it this way, maybe they're too brain fried to go after you. :) *gdr* g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] C++ Terror!
On Mon, 10 Nov 2003, Andy Ross wrote: Gene Buckle wrote: Paul Surgeon wrote: Why does C++ scare you? Well scare is probably too strong a word. :) I'm just unfamiliar with it. I can follow C ok, but the object references tangle me for some odd reason. If C++ doesn't scare you, you have no business using it. Hehehe. It's as good an excuse as any to stick with Pascal. :) Sorry, but that was just too open. I had to take the shot. But seriously, there's more truth in that statement than a sarcastic retort like it deserves. The time to run screaming from a project is the moment the architect declares that it *has* to be written in C++ because no other language will do. I'm serious; use with caution. :) I'll poke it with a stick long enough to make it do what I need and then I'll leave it all angry and ready to bite...someone else. :) I'm going to talk to Peter Dowson about modifying WideFS for use with FlightGear now that I've got the barest inkling of what the generic network frame can handle. We'll see how it goes. I may try building a small module that would direct joystick movement from my EPIC card into the sim and see how bad the latency is. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C++ Terror!
Gene Buckle writes: I'm going to talk to Peter Dowson about modifying WideFS for use with FlightGear now that I've got the barest inkling of what the generic network frame can handle. We'll see how it goes. As far as I understand WideFS, FlightGear can do all that already. You can set up one copy to be a master, and any number of additional copies to be slaves. For each display channel you can specify view offset direction and fov. You can set up anything from a simple 3 monitor display system to some huge convoluted mess if you want to gang up 20 machines. I wasn't clear. I would like to try to get Peter to _modify_ WideFS to utilize the FGFS network interface so that packages like Project Magenta or SquawkBox could be used unmodified with FGFS. I may try building a small module that would direct joystick movement from my EPIC card into the sim and see how bad the latency is. I did something similar on an old agwagon sim I had access to once. Fancy old joystick ... I write a little program that could read the joystick and blast positions to flightgear via the net. Seemed to work ok. Latency wasn't too bad. Ok. I may give it a shot with the analog ports on a Phidget too. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
