Re: [Flightgear-devel] Taxiway editors
On Thu, 20 Nov 2003, Bernie Bright wrote: I'm working on an AFCAD-like taxiway editor for the FlightGear Scenery Designer, http://sourceforge.net/projects/fgsd/. Checkout the taxiway_editor_3 branch. Most of the basic editing functionality is present. The resultant output is an xml file. Note, recent changes to fltk v2 means my stuff won't compile any more. I will fix it real soon now. I tried building fgsd the other day (I've got a bunch of objects I want to place), and it failed rather spectacularly, so I'm guessing I have an incompatible fltk lib installed - presumably the taxiway editor would suffer from the same problem. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taxiway editors
On Wed, 19 Nov 2003, David Luff wrote: I assume you're working on UK airfields :-) How'd you guess... It seems a shame not to be able to taxi up to the RAF c-type hangar I've modelled - past the tower and signals square, after flying over an RAF station full of H blocks :-) Practice with blender really does help you get a LOT faster at this sort of thing. I'll try and get some pics up later. However, if that's what you want to do (edit and create the raw x-plane type taxiways) then I'll have a hack at it - I reckon about 4 - 6 weeks to get something usable by the keen. It should be quite easy to overlay OS grid lines as well to help you line up. That's really what I'm after - although being able to edit the logical stuff too so that it can be used with the AI code would also be very handy. OS grid lines would really help too. ANYTHING has got to be quicker than editing it all by hand and checking the layout in the cgi script I did some months ago! -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taxiway editors
Jon Stockill wrote: On Thu, 20 Nov 2003, Bernie Bright wrote: I'm working on an AFCAD-like taxiway editor for the FlightGear Scenery Designer, http://sourceforge.net/projects/fgsd/;. Checkout the taxiway_editor_3 branch. Most of the basic editing functionality is present. The resultant output is an xml file. Note, recent changes to fltk v2 means my stuff won't compile any more. I will fix it real soon now. I tried building fgsd the other day (I've got a bunch of objects I want to place), and it failed rather spectacularly, so I'm guessing I have an incompatible fltk lib installed - presumably the taxiway editor would suffer from the same problem. Hey guys, if you don't bother sending a warning notice on the mailing list, don't complain it don't works. Anyway, Paul Surgeon warns me and it is now fixed. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] concorde
Jon S Berndt writes The next simplest thing would be to fly to wherever the user is and hold their hand as they type. Jon Thanks Jon I'll have the bed made up in the spare room.When can I expect you LOL. Cheers Innis The Mad Aussi P.S Will fill fridge with beer. _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taxiway editors
On Thu, 20 Nov 2003, Frederic BOUVIER wrote: Hey guys, if you don't bother sending a warning notice on the mailing list, don't complain it don't works. I don't warn you because I expect this kind of thing from CVS versions occasionally - I just try again a few days later when things have got themselves back in sync. If it continues to fail then I'd let you know. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taxiway editors
On 11/20/03 at 11:18 AM Jon Stockill wrote: On Wed, 19 Nov 2003, David Luff wrote: I assume you're working on UK airfields :-) How'd you guess... :-) It seems a shame not to be able to taxi up to the RAF c-type hangar I've modelled - past the tower and signals square, after flying over an RAF station full of H blocks :-) Practice with blender really does help you get a LOT faster at this sort of thing. I'll try and get some pics up later. However, if that's what you want to do (edit and create the raw x-plane type taxiways) then I'll have a hack at it - I reckon about 4 - 6 weeks to get something usable by the keen. It should be quite easy to overlay OS grid lines as well to help you line up. That's really what I'm after - although being able to edit the logical stuff too so that it can be used with the AI code would also be very handy. OS grid lines would really help too. ANYTHING has got to be quicker than editing it all by hand and checking the layout in the cgi script I did some months ago! OK, I've hacked something up: www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p2-preAlpha-w32bin.zip - Windows Binary (statically linked) [267K] www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p2-preAlpha-src.tar.gz - source and makefile for Linux [38K], requires wxGTK-dev. Taxiways can be individually rotated, translated, and altered in size, and can be added. Pressing 'w' writes them out in FG format to ICAO.dat (where ICAO is the code of the airport being worked on), from where they can be pasted into runways.dat. No deletion or undo yet!!! So far it's all using the keyboard, not the mouse. The runways cannot be edited, and a real FlightGear airport probably needs to be loaded to start with (ie. at least one runway is needed to set the airport position). Instructions and keys are as below: - Needs runways.dat in working directory. - Use 'LoadRawAirport' menu entry and enter ICAO code. - F4/F5 zoom in/out. - arrows pan. - j/k - if no taxiways are selected, rotates all taxiways (not runways) about the *airport* origin. If a taxiway is selected, rotates that taxiway about the *selected taxiway* origin. Pressing shift (ie J/K) increases the rotation speed, but reduces the resolution. - d/f/r/c translate all taxiways if none selected, or only the selected one if one is selected. Once again, shift increases speed. - t adds a taxiway at the airport origin with selection. - l/L increases/decreases the length of a taxiway. (Thats little el and big el, not eye and el!!!). - o/O increases/decreases the width of a taxiway. - w writes out all taxiways in FG format to ICAO.dat. - TAB selects the next taxiway (cycles through the list). One position in the list is no selection. - BACKSPACE selects the previous taxiway. - ESC removes the selection from all taxiways. Please let me know if it works, particularly if it compiles OK. Feedback should increase the pace of development :-) Have fun, looking forward to the screenshots, Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taxiway editors
On Thu, 20 Nov 2003, David Luff wrote: Please let me know if it works, particularly if it compiles OK. Feedback should increase the pace of development :-) It compiles correctly on slackware 9.1, looks to be just the job - I'll give it a proper test drive later. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Terrain blacking out randomly
I am running the ready to run Windows executables of FG version 9.3. When I fly, every couple of minutes the terrain goes completely black for a couple of frames and the returns to normal. However, sky does not go black. My computer has an Intel Pentium 2.53 GHz processor, an ATI Radeon Pro graphics card , 0.5 GB of RAM and runs Windows 2000. I have not had this problem on earlier builds of FG. Has anyone else experienced this problem? Does anyone know what could be causing the problem? Hoyt Fleming ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] New timer code ported onto old
I wrote: This drop includes a new, non-Nasal FlightGear subsystem: FGTimerMgr. This is a heap-based priority queue implementation that manages timeout callbacks for anyone that asks. Curt rapidly pointed out that I'd missed the existence of the SGEventMgr class, which does very similar things. It didn't *quite* do what I wanted, so I ported my new stuff onto its interface instead. But I want everyone to try/test the script engine, so you can't have it independently. :) http://www.plausible.org/andy/fg-nasal-1.2.tar.gz [It's really easy: drop the SimGear files into your simgear tree and rebuild. Drop the source files into your FlightGear tree and rebuilt. Drop the data files into your base package and run. Press Shift-C to rotate through the various example Nasal functions.] API changes: There used to be an API where you could add a SGSubsystem to the event manager, which would call the subsystem's update() method periodically. This was unused. It also duplicated functionality in the SGSubsystemMgr, which *also* calls the update() method out of the main loop. This is probably dangerous, since someone who misunderstands the API will get doubled update() calls with no way to tell the difference. It was dead code; I yanked it. The add() methods have split into addTask(), which adds a repeating callback that matches the old API, and addEvent(), which adds a one-shot event which matches my Nasal settimer() usage model. There is a boolean simtime you can pass to indicate that you want simulated time or real time. The default, which matches the old implementation, is real time. I ported the existing usages over to the realtime model, since that preserves compatibility. I didn't audit the existing stuff to see if it should have been using simtime all along. [NEWS FLASH: I just discovered that this feature doesn't work. The main loop passes a zero dt argument to update() when the simulator is paused. I'll look at ways of fixing this, but I'll leave the API as-is. Clearly some things, like user-interface timeouts and animations, are going to want access to real timeouts independant of simulator time.] The time numbers used to be integers specifying milliseconds. They are now doubles in units of seconds; this matches the usage in SGSubsystem::update(), and is generally cleaner IMHO. Internal changes: The add methods still accept the name argument for debugging. But they throw it away. It doesn't get stored in the event objects. Copying a string for every event invocation seemed a little like overkill to me. Algorithmic superiority. This one is a priority queue, so it takes O(logN) time to insert a new event or extract the next one. The old one had to do an O(N) search through all the events every frame. It's a non-issue now, but as we move towards thousands of events (who was it that was talking about AI handling for hundreds of ground vehicles?), this will be significant. Anyway, try it and see if anything breaks. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: New timer code ported onto old
* Andy Ross -- Thursday 20 November 2003 17:18: Anyway, try it and see if anything breaks. Doesn't compile. Fix: $ diff -u /tmp/source/src/Scripting/NasalSys.cxx NasalSys.cxx --- /tmp/source/src/Scripting/NasalSys.cxx 2003-11-20 16:17:03.0 +0100 +++ NasalSys.cxx2003-11-20 22:11:47.497863448 +0100 @@ -5,7 +5,7 @@ #include plib/ul.h -#include simgear/nasal.h +#include simgear/nasal/nasal.h #include simgear/props/props.hxx #include simgear/misc/sg_path.hxx #include simgear/structure/commands.hxx $ diff -u /tmp/source/src/Scripting/NasalSys.hxx NasalSys.hxx --- /tmp/source/src/Scripting/NasalSys.hxx 2003-11-19 22:54:31.0 +0100 +++ NasalSys.hxx2003-11-20 22:12:53.117887688 +0100 @@ -3,7 +3,7 @@ #include simgear/misc/sg_path.hxx #include simgear/structure/subsystem_mgr.hxx -#include simgear/nasal.h +#include simgear/nasal/nasal.h //#include Main/fgtimer.hxx What I like about PSL is that I don't have to learn yet another language. C knowledge is all I need. And what I don't like about Nasal is the name. Makes me too much think of noses. But apart from that, everything worked flawlessly! :-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: New timer code ported onto old
* Melchior FRANZ -- Thursday 20 November 2003 22:25: But apart from that, everything worked flawlessly! :-) i.e. as advertized (the autopilot dialog does indeed not work). And the lib should be called libsgnasal.a if it is to be added to sg. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: New timer code ported onto old
Melchior FRANZ wrote:
Doesn't compile. Fix:
Does compile. You didn't make install your SimGear and are trying
to compile against the source tree instead. :)
But the variant directory structure (nasal.h installs to a different
location than it has in the source tree) is probably a bug. The
proper fix requires modification to simgear/nasal/Makefile.am too, I
think. I'm fuzzy on how this automake stuff works.
What I like about PSL is that I don't have to learn yet another
language. C knowledge is all I need. And what I don't like about
Nasal is the name. Makes me too much think of noses.
Do you know any Javascript? Nasal is very similar. Take a look at
http://www.plausible.org/nasal/sample.nas for a quick tutorial.
Honestly, the syntax is very conventional; almost all the C like
code you can write looks basically the same as it does in C.
The only truly weird thing is that you don't declare functions.
Where most language do something like:
void funcname() { ... } /* C */
sub funcname { ... } # Perl
def funcname(): #
... # Python
function funcname() { ... } // Javascript
Nasal uses:
funcname = func { ... }
That is, the func { ... } expression defines an anonymous function
object, which gets assigned to a plain old variable named funcname.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: New timer code ported onto old
Melchior FRANZ wrote: I never make install in SimGear, but have a link to the simgear dir from /usr/local/include. This has always worked. But it cannot work when the source refers to simgear/nasal.h, although the file is actually in simgear/nasal/nasal.h. You misunderstand. The build system makes no guarantee that the locations of files in the install tree will match their locations in the source tree. This has always worked only because SimGear has adhered to a convention where this is so. The issue of what the #include lines contain is secondary. The install location needs to be modified in the Makefile.am as well, otherwise you will just break people building from an installed tree. If any automake gurus can tell me how to make the nasal.h header appear in a nasal subdirectory, please tell me. :) No. I find it disgusting. HTML pages with ECMA p*ss me off. They tend to not work. Browsers have historically implemented standard Javascript APIs like DOM badly. And web developers have historically done a poor job of handling these incompatibilities. None of that has anything to do with the language. You really should take a look. It's quite sane. Obviously, Nasal isn't a browser extension language and has no DOM implementation, so you're safe. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: New timer code ported onto old
* Andy Ross -- Thursday 20 November 2003 23:46: You misunderstand. The build system makes no guarantee that the locations of files in the install tree will match their locations in the source tree. Yes, and everybody knows that. It's just that making that link was once recommended on this list and has always worked. And I assume that this is no coincidence. =EOT= m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: New timer code ported onto old
Melchior FRANZ wrote: * Andy Ross -- Thursday 20 November 2003 23:46: You misunderstand. The build system makes no guarantee that the locations of files in the install tree will match their locations in the source tree. Yes, and everybody knows that. It's just that making that link was once recommended on this list and has always worked. And I assume that this is no coincidence. =EOT= There are people that don't use automake to build flightgear and they would be gratefull if they could continue to build without having to duplicate stuff. Thanks, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] CVS problem ?
I am getting this tonight : cvs -z3 -q -n update -P (in directory D:\FlightGear\cvs\SimGear\) Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: 'Directory' missingE Protocol error: bad global option -l *CVS exited normally with code 1* Same with TerraGear, SimGear, FG sources and FG data This is with WinCVS 1.2 that comes with cvs 1.11 Do something changed on the server recently ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: New timer code ported onto old
Frederic Bouvier wrote: There are people that don't use automake to build flightgear and they would be gratefull if they could continue to build without having to duplicate stuff. I'm going to have to start writing clearer, I guess. Let me say it again: I *want* to put the nasal.h file into a subdirectory. Tell me how. Editting C++ code is not sufficient. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: New timer code ported onto old
* Andy Ross -- Thursday 20 November 2003 23:46: The install location needs to be modified in the Makefile.am as well, Yes, of course. otherwise you will just break people building from an installed tree. If any automake gurus can tell me how to make the nasal.h header appear in a nasal subdirectory, please tell me. :) I find automake disgusting, too. :-) No wonder that the KDE people finally replaced automake by unsermake (and later by brockenboring ...?). Browsers have historically implemented standard Javascript APIs like DOM badly. Yes, that's the reason why I've never looked into it. It was worthless as a client-side web language. But as a language it may not be that bad. Obviously, Nasal isn't a browser extension language and has no DOM implementation, so you're safe. :) Yes. Hey, it's definitely not going to become the worst language I had managed to learn. ;-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: New timer code ported onto old
On Thu, 20 Nov 2003 15:28:49 -0800 Andy Ross [EMAIL PROTECTED] wrote: Frederic Bouvier wrote: There are people that don't use automake to build flightgear and they would be gratefull if they could continue to build without having to duplicate stuff. I'm going to have to start writing clearer, I guess. Let me say it again: I *want* to put the nasal.h file into a subdirectory. Tell me how. Editting C++ code is not sufficient. Judging from the other Makefile.am files, try adding includedir = @includedir@/nasal to your Makefile.am and re-run automake, etc. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Carrier landings
Here's one that's been bugging me for a while. I never seem to be getting proper terrain elevation hits off of .ac loaded models... things like buildings, bridges, aircraft carriers, etc. I was looking at this tonight and I think I found the problem. The hitlist code wasn't handling the vertex order of triangle strips quite right. Shoot me, but the terrain just uses triangle fans. These were handled correctly. However, .ac models are optimized triangle strips which weren't being handled quite right. I *think* I have this fixed and will commit my change soon. Just for fun, I placed the saratoga off the san francisco coast a ways and was able to land on it. I might as well commit that minor change too so others can play ... just take off out of KSFO and fly a heading of about 300-305 (true). However, there is still an issue (and I will assert that it is a modeling issue perhaps?) The lines painted on the saratoga deck are actually done with raised polygons (by a foot or two) to avoid z-buffer fighting. However the terrain intersection code sees these raised lines so if you move across the deck and hit a line, the aircraft is suddenly become 1-2 feet under the reported surface, this generates excessive gear forces and triggers a crash. Dohhh The saratoga is extremely simplistic. Any one want to take a pass at building a spiffier aircraft carrier model? Ok, and for those of you that worry about these sorts of things, it's a statically placed, non moving aircraft carrier a) so I can find it and b) so I don't have to worry about sticking one DCS object to another. Now, off to see if I can land the seahawk ... Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Carrier landings
Ok, and for those of you that worry about these sorts of things, it's a statically placed, non moving aircraft carrier a) so I can find it and b) so I don't have to worry about sticking one DCS object to another. For certain objects (like a carrier for instance), would it be possible to mark the leaf (or whatever you call the GL object that models the deck of the carrier) as a *moving* object, and associate it with a translational and rotational velocity vector? That way, it is possible for the FDMs to perhaps sense a moving object when they are over one, and take this velocity into account when doing the ground reactions? Additionally, this means we (FDM authors) need to consider adding a catapult device and an arresting cable as forces that can act on an aircraft. I had meant to add parachute decelerators to JSBSim anyhow ... it's probably not that much more of a stretch to add the former two. This could be cool. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] flying under bridges.
Since I was poking around with the terrain intersection code anyway tonight, I made a small modification that allows you to fly under the bridges, then turn around and land on them lengthwise. Essentially, the terrain intersection code only returns hits at or below your current elevation. This should allow you to taxi into (open) hangers, drive through tunnels, and should generally work like you'd expect/hope. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
