Re: [Flightgear-devel] Re: [Flightgear-users] My screen shot.
Andy Ross wrote: Jim Howarth wrote: Ahhh... Well.. I got to it.. Started to fly under it and flightgear crapped out.. No. It just flagged a collision. The FDMs can only ask FlightGear how high above sea level is the ground at this location?. This is fine for doing ground handling on runways. But the problem is that this models the whole world as an elevation field -- there's no notion of under in such a data model. So the second you flight into an area where the tallest scenery object is higher than you, you appear to hit a wall. The existing hit list code works well and runs fast, so it hasn't been tinkered with to try to fix this. The right interface would be a way for the FDM to hand a bunch of line segments (not points; landing gear can compress) to FlightGear and get back an indication of where along that line an intersection occurred. Something like: See tilemgr.cxx line 453: hit = fgCurrentElev(abs_pos_vector, sc, // uncomment next paramater to fly under // bridges and a slightly faster algorithm // but you won't be able to land on aircraft carriers // current_tile-get_terra_transform(), hit_list, hit_elev, hit_radius, hit_normal); Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: [Flightgear-users] My screen shot.
Erik Hofman writes: Andy Ross wrote: Jim Howarth wrote: Ahhh... Well.. I got to it.. Started to fly under it and flightgear crapped out.. No. It just flagged a collision. The FDMs can only ask FlightGear how high above sea level is the ground at this location?. This is fine for doing ground handling on runways. See tilemgr.cxx line 453: ah you beat me to it http://baron.me.umn.edu/pipermail/flightgear-devel/2003-August/020119.html Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: [Flightgear-users] My screen shot.
Andy Ross writes: The existing hit list code works well and runs fast, so it hasn't been tinkered with to try to fix this. The right interface would be a way for the FDM to hand a bunch of line segments (not points; landing gear can compress) to FlightGear and get back an indication of where along that line an intersection occurred. Something like: // Just in case someone is interested in writing this. :) // // Returns true if the line segment intersects. The intersection // point is returned in isect, where a value of 0 indicates point // a, and 1.0 indicates b. bool fgGetSceneryIntersection(Point3D a, Point3D b, float* isect); Somethng like this is easy enough to implement with the current hitlist code but ... I don't understand why the compressability of the gear has any bearing on the point of contact. It is the AC that is changing not the Terrain Note that this is 'almost' supported in the hitlist code now, all one needs do is use the older less optimized form of int FGHitList::IntersectLeaf( ssgLeaf *leaf, sgdMat4 m, sgdVec3 orig, sgdVec3 dir ) inside of FGHitList::IntersectBranch() and add the appropriate changes to the highlevel calling function fgCurrentElev() to fill in your isect list as required from the hitlist. Gotta love those time machines :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ACScript RFC (or FGScript ??)
Yes I would prefer an ac+fdm+autopilot solution strictly for realism purposes -- but anything that instances planes controled by FG needs to be hooked into my network code so that ac status updates can be made visible to all other participants. AIPlane definitly meets some of my needs based on the descriptions and a quick peek at the code. The main area where AIPlane falls short IMO is the hard coded AI functionality -- so here we go: I would like to request your ideas and wishes for an aircraft AI scripting language sufficiently generic in scope to handle piloting any aircraft running on FG. I can see right off that it must be event driven, able to interupt its current procedure/task in response to external inputs, able to process complicated nested procedures with completion of a "statement" based on the current aircraft state or external inputs such as radio message or radar. It must span every level of interaction from "turn the plane to aThis probably doesn't fit your requirements exactly, but for an example you might want to take a look at the following documents:FGScript class reference:http://jsbsim.sourceforge.net/JSBSim/index.htmlExample script:http://cvs.sourceforge.net/viewcvs.py/jsbsim/JSBSim/scripts/c1722.xml?rev=1.14view=markup"Automatic Flight in JSBSim" (PDF)http://jsbsim.sourceforge.net/AutomaticFlightInJSBSim.pdfJSBSim - a FlightGear FDM - apart from driving FlightGear, can also be run by itself in a standalone application in a sort of batch run mode. This is useful for testing and development. To *really* get some good functionality out of standalone JSBSim required us to develop a scripting capability as well as inherent autopilot functionality. As I have mentioned before, JSBSim + script + autopilot =~ GNC, where the scripting provides "G"uidance, the FDM provides "N"avigation, and the FCS/Autopilot provides "C"ontrol. To see what an autopilot definition file could look like, see the simple wing leveler put together completely in a configuration file using JSBSim flight control building blocks (components): http://cvs.sourceforge.net/viewcvs.py/jsbsim/JSBSim/control/c172ap.xml?rev=1.8view=markup I hope these give you someideas that will be helpful. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: David Luff [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 5:18 AM Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??) I not trying to put you off - I welcome all efforts in this area. I'm a believer in starting simple and getting some code out there though. Personally, for a first iteration of a multiplayer server, I'd turn the ATC and AI off in all the clients, and just get to the point where several of us could connect to the server, fly together at one airport without starting on top of each other, and possibly exchange messages. Once we can actually fly together on it, it'll seem much more tangible. Good luck! Cheers - Dave The only reason I'm not done with the fly together code is I'm packing to move from Kentucky to Texas this weekend -- there is a uhaul in front of my apartment stacked to the ceiling with stuff and we still got loading yet to do today :) Is there anything in the airport datasets that tells where the ends of the runways are ?? and perhaps where the taxiways leading up to the runway are so I can have the server stack up planes waiting for takeoff when they connect to the server ?? Putting me off is not possible :) I think I got this AI engine idea wired at the engine level -- and there is no reason that at the lowest level, the scripting language can't directly maniplulate the elevators/ailerons/rudder/flaps/etc just like the kb/stick controls do. Just means a larger core library of procedures needs to be created -- doesnt matter to me if those procedures are hard-coded (a.k.a autopilot c++ code) or scripted (directly drive the fdm like the kb/stick controls) -- just need to decide which one is the best for the initial implementation :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ACScript RFC (or FGScript ??)
The only reason I'm not done with the fly together code is I'm packing to move from Kentucky to Texas this weekend Good move. :-) ;-) Where in Texas? Jon (Houston) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
On 11/13/03 at 8:13 AM John Barrett wrote: The only reason I'm not done with the fly together code is I'm packing to move from Kentucky to Texas this weekend -- there is a uhaul in front of my apartment stacked to the ceiling with stuff and we still got loading yet to do today :) I'm looking forward to flying on it :-) Is there anything in the airport datasets that tells where the ends of the runways are ?? No, only the origin (unless I'm mistaken), but you can see how I get the ends in void FGAILocalTraffic::GetRwyDetails() in AILocalTraffic.cxx. and perhaps where the taxiways leading up to the runway are so I can have the server stack up planes waiting for takeoff when they connect to the server ?? Not yet (except for KEMT and that format is going to get replaced). Bernie Bright and myself are both working on AFCAD-like taxiway/facilities editors, and once we agree on an acceptable file format, put loading support into the AI/ATC code, and write a tutorial on how to do it, logical taxiway support should grow. I've decided to go ahead and add GA AI traffic flying VFR at and/or between all the tower controlled airports before that though by simply starting them roughly where a hold short might be next to the threshold end of the runway, and finishing them by simply disappearing after turning off the runway. I've found that the following gives a roughly acceptable initial position waiting for the runway: orthopos = Point3D((rwy.width / 2.0 + 10.0) * -1.0, 0.0, 0.0); // TODO - set the x pos to be +ve if a RH parallel rwy. pos = ortho.ConvertFromLocal(orthopos); pos.setelev(aptElev); hdg = rwy.hdg + 90.0; // TODO - reset the heading if RH rwy. (Not in CVS yet). ortho is an instance of the ATC runway aligned simple x-y projection found in ATCProjection.[ch]xx. However, for user operated traffic, the chance of not being placed on a rendered taxiway might be more unacceptable than for AI traffic. The interface to the taxiway stuff when added will be through FGGround (as it is now for the KEMT hardwired taxiways). At the moment the return values are nodes and arcs, and thus the AI traffic must have some knowledge of the internal structure to navigate it. It could easily be modified to supply you with just a lat/lon location and heading of 1st, 2nd, 3rd etc hold position, subject to the mentioned proviso that at the moment we don't have any definition files or load an agreed format (yet). Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: Jon Berndt [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 8:33 AM Subject: RE: [Flightgear-devel] ACScript RFC (or FGScript ??) The only reason I'm not done with the fly together code is I'm packing to move from Kentucky to Texas this weekend Good move. :-) ;-) Where in Texas? Jon (Houston) Plano -- just north of dallas :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: David Culp [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 11:48 PM Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??) I would like to request your ideas and wishes for an aircraft AI scripting language sufficiently generic in scope to handle piloting any aircraft running on FG. My generalized AI airplanes were originally going to be defined in preferences.xml (like the ai-tanker), something like this for each instance desired: ai-plane typeprop-transport/type modelAircraft/DC6/Models/DC6-model.xml/model start-time2.00/start-time scriptScripts/ai_script01.xml/script /ai-plane The above would instantiate the plane (or truck, boat), assign it a visual model, indicate how many minutes into the sim session it should appear, and indicate the path to this object's script. The script would look like: script entry on typeelapsed-time/type value0.50/value /on lat35.35628/lat lon125.573899/lon elev369.5/elev heading350.0/heading /entry entry on typemessage/type valuetakeoff-you-hoser/value /on task typetakeoff/type altitude5000.0/altitude /task /entry ... and so forth. The waypoints could be triggered by elapsed time, UTC time, reaching a waypoint, or message. The details of the takeoff would be handled by the FDM, knowing what speeds and climb rate are suitable for a prop-transport. Dave -- David Culp davidculp2[at]comcast.net Ok -- all you have done is state that takeoff is a procedure to be followed without defining the procedure (i.e. its hard coded and there is no variation from that procedure) procedure takeoff(heading, target_altitude) { ground=altitude; throttle=90; brakes=off; flaps=15; on (speed = 140) { elevators = 20; // pull back on the stick } on (alititude ground+50) { gear=up; // if the plane has retractable gear } on (alititude ground+100) { turnto(heading); // nested procedure, does its actions and events // note -- that events are stacked -- any events defined here are // still active unless overridden by the nested procedure. When the // nested procedure completes, overridden events take effect again // also note that since this is in an event check, it gets checked every // update loop to maintain the heading } on (climbrate 100) { elevators--; } on (climbrate 100) { elevators++; } on (altitude == target_altitude) { levelplane(target_altitude); // yet another scritped procedure return; } } } I'm sure there are further refinements that could be made, but you get the general idea :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
John Barrett writes: on (climbrate 100) { elevators--; } on (climbrate 100) { elevators++; } Look out below (and above) which ever comes first! :-) 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] ACScript RFC (or FGScript ??)
- Original Message - From: John Barrett [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 8:45 AM Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??) on (speed = 140) { elevators = 20; // pull back on the stick } should have been: on (speed == 140 altitude=ground) { elevators = 20; // pull back on the stick } ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer RFC -- wire protocol spec --preliminary
- Original Message - From: Gerhard Wesp [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 9:29 AM Subject: 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)? bandwidth and performance I could understand human readable for a limited system, but not for a setup that could potentially be handling 100s of planes, and while for GA sims, it may not be needed, I have a little more than that in mind :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
On 11/13/03 at 8:15 AM Curtis L. Olson wrote: John Barrett writes: on (climbrate 100) { elevators--; } on (climbrate 100) { elevators++; } Look out below (and above) which ever comes first! :-) I used to try flying the Navion like that when I first downloaded FG. I never ever cleared that ridge after takeoff from P20 until I forced myself to start pushing the stick down when I wasn't climbing enough. Must check and see if the Navion still works sometime - I've always thought it would be nice to do a 3D model and a panel for it sometime as a tribute to where we've come from. Probably never get round to it though... Cheers - Dave ___ 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] ACScript RFC (or FGScript ??)
- Original Message - From: David Culp [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 9:24 AM Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??) Ok -- all you have done is state that takeoff is a procedure to be followed without defining the procedure (i.e. its hard coded and there is no variation from that procedure) Actually, I don't see a need for the AI airplanes to have brakes, elevators, flaps and such. Our visions of AI traffic are much different. Dave -- David Culp davidculp2[at]comcast.net Very different indeed -- I'm trying to model the pilots deciscion processes and interactions at a general level sufficient to write procedures to do ANYTHING that can be done with a plane. Directly controlling an aircraft via FDM just insures that the generic procedures dont exceed the performance capabilities of a specific plane, and can be tailored to specific aircraft when needed by overriding library procedures with aircraft specific procedures. Equally, the script engine output could be taken at a level where there is no FDM to control, for instance the AIPlane class, simply by defining hard coded procedures for that specific interface that override the low level FDM interface, and registering them with the script engine before starting a script. (thats getting complicated, but its much more possible if I know up front that I need to handle multiple aircraft interfaces) Hmmm -- that actually answers the problem I was trying to solve -- the class that interfaces the script engine to a specific aircraft class must define what low level is for the engine by registering the appropriate procedures to control the aircraft, the FDM interface would register routines to control elevators/ailerons/rudder/etc. The AIPlane interface would register turnto(heading) and other more abstract procedures, incidentally cutting out all the lower level scripting designed to control a plane via FDM. Therefore low level control procedures need to be defined in layers so that implementors can pick where to hook in, and have a well defined list of procedures that must be implemented to hook in at that level. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
John Barrett writes: Very different indeed -- I'm trying to model the pilots deciscion processes and interactions at a general level sufficient to write procedures to do ANYTHING that can be done with a plane. Directly controlling an aircraft via FDM just insures that the generic procedures dont exceed the performance capabilities of a specific plane, and can be tailored to specific aircraft when needed by overriding library procedures with aircraft specific procedures. I'm jumping into the middle of this conversation, but let me make a few comments. I envision a model where a single client computer will be responsible only for the location of it's single interactive aircraft. It sends it's the information about it's single aircraft to the server. From a multi-player standpoint. Any additional AI aircraft to be seeded into the world, should be handled by the server. The server will create and delete them, the server will fly them, script them, etc. etc. This way, an instance of FlightGear needs to send the position of the aircraft it is responsible for to the server, and then it will receive the positions of any other aircraft (AI or human controlled) in the vicinity. I think step #1 should be to get the client/server stuff working without worrying about any AI aircraft at all. Let's get the communication going so people can fly together. Once that is fleshed out, we can worry about seeding additional AI aircraft into the world to make things more interesting. At that point we can decide how to fly them, script them, animate them, etc. But I think most of that should be handled on the server side. A single instance of flightgear would get the same information on other aircraft regardless of whether they are human or AI controlled. I think this should be kept separate from any system where FlightGear populates it's own world with AI aircraft. I think that should get completely turned off when the multiplayer stuff is activated. 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] Electrical system work..
Gene Buckle wrote: 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. 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. 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. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Terrain Following
I have a need to develop a simulation of a terrain following system. The system is presented a flight corridor (start point, end point, and corridor width) and need to return the location, and elivation, of the highest point in that corridor. I remember seeing some discussion a while back concerning how to get the terrain elevation for random points, but didn't follow it too closely. Can anyone give me some information as to where I can start looking? On a related point (really, it is), if a company wanted to pay to have modifications made to FlightGear, is there anyone in the community that does this? The primary interest is for the terrain following system, but I would love to eventually have JSBSim modified so I could use it to drive some GPS and inertial simulations. First, I will need to test the water with the terrain system. Thanks, Jonathan Polley Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
John Barrett wrote: - Original Message - From: David Culp [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 9:24 AM Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??) [Dave's message] -- [- Dave's Signature] David Culp davidculp2[at]comcast.net [John's message] John, your email is malformed. :) You include the original text inline, rather than quoted (prefixed by some combination of and whitespace). It looks like you are clicking forward rather than reply to compose your mail. This might seem like a meaningless nit, but it actually causes problems. In this case, the line containing -- above is interpreted by my mail reader (Mozilla) as the beginning of a signature, which get colorized differently than the rest of the mail. There is nothing to tell the reader where the .sig ends and where your message begins, so your message ends up a dull, hard-to-read gray. Even worse, Mozilla helpfully *removes* the signature (and therefore all of your text!) when it quotes the mail into an editor buffer for a reply. Believe it or not, this stuff is actually specified in various RFCs. Microsoft has a horrific record of compliance with those standards, of course, but nonetheless I *have* seen correctly formatted quotes emerge from Outlook Express users. :) Andy ___ 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
[Flightgear-devel] ACScript RFC (or FGScript ??)
[Starting a new thread. John's reply was burried in the parent thread] John Barret wrote: I would like to request your ideas and wishes for an aircraft AI scripting language sufficiently generic in scope to handle piloting any aircraft running on FG. There is some support already in place for using Plib's psl language in FlightGear; it's a sane minilanguage with C-like syntax and semantics (basic types and functions, basically; no pointers, structs or arrays). It talks to the rest of FlightGear through the property tree. You will want to investigate this first; I haven't tried it yet. I'd caution against a special-purpose language; these things are almost always just as hard to write as real languages are, and never quite do as much as you hoped. I'd stick with a general purpose language, whatever you do. And now the plug. :) I wrote a scripting language of my own at one point (http://www.plausible.org/nasal) which is closer to Perl or Javascript. It's semantically richer than PSL, supporting all the stuff you expect like vectors, hashes/objects, garbage collection, et. al. It's also quite small; a little over 100k of source code these days. No work has been done to integrate it into FlightGear/SimGear (I wrote it for my own game project last spring), but I'd be happy to do so if there was interest. Languages are like religions though. Some people are going to hate the idea, some people are going to like it except for one or two things that *have* to be fixed first, some will want to use a different language. No one seems to want to use PSL yet, though, so it seems to me like the door is still open for alternatives. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-users] My screen shot.
Norman Vine wrote: Somethng like this is easy enough to implement with the current hitlist code but ... I don't understand why the compressability of the gear has any bearing on the point of contact. It is the AC that is changing not the Terrain Gear don't always compress perpendicular to the ground, and not all aircraft contact points are landing gear. Wing tips, for example, might hit the ground at funny angles or hit terrain objects like buildings that aren't flat. The location of ground contact (and thus the point of force application on the aircraft) is going to be somewhere on the line between the point of maximum gear compression and maximum gear extension. Where? At the point where this line segment interects the terrain polygons. (Strictly, at the intersection nearest the max compression point if there is more than one). Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: [Flightgear-users] My screen shot.
Andy Ross writes: Norman Vine wrote: Somethng like this is easy enough to implement with the current hitlist code but ... I don't understand why the compressability of the gear has any bearing on the point of contact. It is the AC that is changing not the Terrain Gear don't always compress perpendicular to the ground, and not all aircraft contact points are landing gear. Wing tips, for example, might hit the ground at funny angles or hit terrain objects like buildings that aren't flat. The location of ground contact (and thus the point of force application on the aircraft) is going to be somewhere on the line between the point of maximum gear compression and maximum gear extension. Where? At the point where this line segment interects the terrain polygons. (Strictly, at the intersection nearest the max compression point if there is more than one). FYI this *is* exactly how the current terrain elevation code works The hitlist is populated with all points that intersect a given line with the terrain. i.e. all you need to do is set up the high level call and then examine the populated hitlist structure when the call returns using the unoptimized fgIntersectList() call I mentioned earlier Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Terrain Following
Jonathan Polley writes: I have a need to develop a simulation of a terrain following system. The system is presented a flight corridor (start point, end point, and corridor width) and need to return the location, and elivation, of the highest point in that corridor. Hi Jonathan I really can't think of an easily implementable mechanism for doing this in FlightGear. However I guess one could do a top down 'rendering' similar to what Atlas does keeping tack of maximum value seen inside of the corridor. If you are happy getting an answer back via a network request from a propriatary system give me shout off list. I just happened to have implemented almost an identical system for marine use with sounding data for water depth several years ago that is *very* quick, but it is not Open Source. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
David Culp [EMAIL PROTECTED] said: Ok -- all you have done is state that takeoff is a procedure to be followed without defining the procedure (i.e. its hard coded and there is no variation from that procedure) Actually, I don't see a need for the AI airplanes to have brakes, elevators, flaps and such. Our visions of AI traffic are much different. Agreed. It isn't practical with standard hardware to run a full fdm/ap for each AI instance. There needs to be a very rudementary fdm for AI aircraft. No fancy atittude and control stuff. Ground traffic is potentially very complex but in air behavior should be fairly easy. Fly! used to run their AIs for approaches and basically just do a series of touch and gos. This would be easy enough to accomplish by adapting the ils/gs and ap code. But the commands for adjustments should just involve direct changes to attitude and speed (smoothed in a linear fashion), rather than translating control inputs into aerodynamic responses. Otherwise we'll all need a cluster of 3ghz pc's just to run this thing. It certainly would be the only way to mix AI traffic with live pilots when one participant is running in a non-dedicated peer host server mode (which is, IMHO, a worthy goal). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: Curtis L. Olson [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 10:15 AM Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??) John Barrett writes: Very different indeed -- I'm trying to model the pilots deciscion processes and interactions at a general level sufficient to write procedures to do ANYTHING that can be done with a plane. Directly controlling an aircraft via FDM just insures that the generic procedures dont exceed the performance capabilities of a specific plane, and can be tailored to specific aircraft when needed by overriding library procedures with aircraft specific procedures. I'm jumping into the middle of this conversation, but let me make a few comments. I envision a model where a single client computer will be responsible only for the location of it's single interactive aircraft. It sends it's the information about it's single aircraft to the server. From a multi-player standpoint. Any additional AI aircraft to be seeded into the world, should be handled by the server. The server will create and delete them, the server will fly them, script them, etc. etc. And I envision a client that handles multiple AI aircraft on behalf of a server thats plenty busy enuf handling message passing and other management functionality (this client really it could be considered part of the server, but so much of the code is the same compared to a client, there really isnt a reason not to leverage the existing client code and distribute the processing to other machines, and the same code will be in the server so if the requirements are light enough, the server could be instancing the planes) This way, an instance of FlightGear needs to send the position of the aircraft it is responsible for to the server, and then it will receive the positions of any other aircraft (AI or human controlled) in the vicinity. I dont see the AIplanes being used on an FG instance running a user plane all that often, but it may happen if a user is running a small server for a simple scenario and a few friends I think step #1 should be to get the client/server stuff working without worrying about any AI aircraft at all. Let's get the communication going so people can fly together. I'm almost there except that I'm packing to move -- I just wanted to talk ahead so I would know where I was going next and make sure the protocol was up to handling the planned usage scenarios Once that is fleshed out, we can worry about seeding additional AI aircraft into the world to make things more interesting. At that point we can decide how to fly them, script them, animate them, etc. But I think most of that should be handled on the server side. A single instance of flightgear would get the same information on other aircraft regardless of whether they are human or AI controlled. I think this should be kept separate from any system where FlightGear populates it's own world with AI aircraft. I think that should get completely turned off when the multiplayer stuff is activated. I think it can all work together with minimal problems based on what I have gleaned from the code so far -- its a question of how the server scales up from a few buddies flying with no or few AI planes, up to 100s of flyers talking to a server managing 100s if not 1000s of human and AI driven aircraft. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: Andy Ross [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 10:29 AM Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??) John Barrett wrote: - Original Message - From: David Culp [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 9:24 AM Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??) [Dave's message] -- [- Dave's Signature] David Culp davidculp2[at]comcast.net [John's message] John, your email is malformed. :) You include the original text inline, rather than quoted (prefixed by some combination of and whitespace). It looks like you are clicking forward rather than reply to compose your mail. This might seem like a meaningless nit, but it actually causes problems. some of my messages get the indents, some dont -- I dont know why In this case, the line containing -- above is interpreted by my mail reader (Mozilla) as the beginning of a signature, which get colorized differently than the rest of the mail. There is nothing to tell the reader where the .sig ends and where your message begins, so your message ends up a dull, hard-to-read gray. Even worse, Mozilla helpfully *removes* the signature (and therefore all of your text!) when it quotes the mail into an editor buffer for a reply. My apologies. I've never had a mail reader that messed with the message content in that way, nor heard of one that did before today Believe it or not, this stuff is actually specified in various RFCs. Microsoft has a horrific record of compliance with those standards, of course, but nonetheless I *have* seen correctly formatted quotes emerge from Outlook Express users. :) Like this message did it right, but sometimes it doesnt and I dont know why. Sometime I even insert the indents by hand (when I notice it) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: Andy Ross [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 10:46 AM Subject: [Flightgear-devel] ACScript RFC (or FGScript ??) [Starting a new thread. John's reply was burried in the parent thread] John Barret wrote: I would like to request your ideas and wishes for an aircraft AI scripting language sufficiently generic in scope to handle piloting any aircraft running on FG. There is some support already in place for using Plib's psl language in FlightGear; it's a sane minilanguage with C-like syntax and semantics (basic types and functions, basically; no pointers, structs or arrays). It talks to the rest of FlightGear through the property tree. You will want to investigate this first; I haven't tried it yet. I dont know if you caught the post where I gen'd up a simple procedure to give some idea of the action/event structure that I would like the language syntax to describe. Everything is basically off of FDM variables and simple commands to the plane. I would need to get much deeper into PSL to see if it could be used as the core of a scripting engine that could handle nested/stacked event handlers. The C like syntax is a definite plus, but I'm trying to hide the details of the event management logic from the AI designers. Let them concentrate on flying the plane and not worrying about how to implement state/event code. I'd caution against a special-purpose language; these things are almost always just as hard to write as real languages are, and never quite do as much as you hoped. I'd stick with a general purpose language, whatever you do. I'd like all the basic features of C, but with the event extensions, A procedure should be nothing but a script that sets up the preconditions for the procedure and a set of event handlers that do the routine adjustments required until the termination event for the procedure occurs. Event handlers are sub-scripts that execute when certain conditions are met, and the conditions are tested every update() call to the engine. A procedure can use a nested procedure with its own setup and events that stack on top of the callers events. And lastly, when a nested procedure is called, the engine should check if there is already an instance of that procedure running, and if so, do nothing. (this can be determined by checking for any entries on the event stack that are tagged as belonging to the named procedure) And now the plug. :) I wrote a scripting language of my own at one point (http://www.plausible.org/nasal) which is closer to Perl or Javascript. It's semantically richer than PSL, supporting all the stuff you expect like vectors, hashes/objects, garbage collection, et. al. It's also quite small; a little over 100k of source code these days. No work has been done to integrate it into FlightGear/SimGear (I wrote it for my own game project last spring), but I'd be happy to do so if there was interest. If I'm going to use some other scripting engine as a basis to reduce development time, I'm equally open to your language or PSL as the language core, so long as some way can be found to graft on the event handler model outlined above :) The only requirement I would have for using an existing script engine as a core would be the ability to map script variables to C++ variables. The interface class that ties the engine to a specific aircraft class would be responsible for setting up those mappings, as well as registering any hard-coded procedures specific to that aircraft interface. Languages are like religions though. Some people are going to hate the idea, some people are going to like it except for one or two things that *have* to be fixed first, some will want to use a different language. No one seems to want to use PSL yet, though, so it seems to me like the door is still open for alternatives. :) And thats exactly where I'm at -- C/PSL is nice, but there are these darn features that I dont feel that I can live without :) Based on my experience working with the TCL and JS engines in other projects, what I want should not be horribly difficult to graft on to an existing engine. All that is required is the addition of a few new statements (procedure, on(event), and endproc) and the low level code to handle what they do, and the creation of an update_events() method to process the event tree. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
John Barrett writes: And I envision a client that handles multiple AI aircraft on behalf of a server thats plenty busy enuf handling message passing and other management functionality (this client really it could be considered part of the server, but so much of the code is the same compared to a client, there really isnt a reason not to leverage the existing client code and distribute the processing to other machines, and the same code will be in the server so if the requirements are light enough, the server could be instancing the planes) Just asking questions here ... let's say that 10 people want to meet up and fly around a particular airport, and each of those 10 interactive sessions by default generates 10 AI aircraft each to make the skies interesting, things could get quite busy. It seems like you'd have to come up with some protocol to arbitrate who instantiates and controls which aircraft distributed accross all the different clients. That sounds like it could get really complex in order to do correctly with out any goof ups. I'm not saying it can't be done, just that it seems like this could quickly grown into an extremly complex system. 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] ACScript RFC (or FGScript ??)
Curtis L. Olson wrote: John Barrett writes: And I envision a client that handles multiple AI aircraft on behalf of a server thats plenty busy enuf handling message passing and other management functionality (this client really it could be considered part of the server, but so much of the code is the same compared to a client, there really isnt a reason not to leverage the existing client code and distribute the processing to other machines, and the same code will be in the server so if the requirements are light enough, the server could be instancing the planes) Just asking questions here ... let's say that 10 people want to meet up and fly around a particular airport, and each of those 10 interactive sessions by default generates 10 AI aircraft each to make the skies interesting, things could get quite busy. It seems like you'd have to come up with some protocol to arbitrate who instantiates and controls which aircraft distributed accross all the different clients. That sounds like it could get really complex in order to do correctly with out any goof ups. I'm not saying it can't be done, just that it seems like this could quickly grown into an extremly complex system. I think he meant just one instance of FlightGear feeding the server with the AI traffic (just like it was a client, but in this case a very special one). This seems like a good approach because the AI generator could run on one, or several different machine(s). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: Curtis L. Olson [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 1:19 PM Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??) John Barrett writes: And I envision a client that handles multiple AI aircraft on behalf of a server thats plenty busy enuf handling message passing and other management functionality (this client really it could be considered part of the server, but so much of the code is the same compared to a client, there really isnt a reason not to leverage the existing client code and distribute the processing to other machines, and the same code will be in the server so if the requirements are light enough, the server could be instancing the planes) Just asking questions here ... let's say that 10 people want to meet up and fly around a particular airport, and each of those 10 interactive sessions by default generates 10 AI aircraft each to make the skies interesting, things could get quite busy. It seems like you'd have to come up with some protocol to arbitrate who instantiates and controls which aircraft distributed accross all the different clients. That sounds like it could get really complex in order to do correctly with out any goof ups. I'm not saying it can't be done, just that it seems like this could quickly grown into an extremly complex system. Why is an interactive session by default generating AI aircraft without a loaded scenario to control those aircraft ?? The server should be loading the scenario. Having an airport spawn aircraft just because someone is close by the airport should not be a default behavior of the simulator. Similarly, if a client is acting as a adjunct to a server, it will need a scenario loaded from the command line, or provided by the server to control its spawning and behavior of AI planes. Without a scenario loaded, or a connection to a server, its just you all by your lonesome (which I had thought was the situation given my experience loading up FG and flying around with the default settings) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
Without a scenario loaded, or a connection to a server, its just you all by your lonesome (which I had thought was the situation given my experience loading up FG and flying around with the default settings) The AI already in place is little used because it's tied to one airport and needs some generalizing. I'm looking forward to network flying, including network AI, but I hope development of local machine AI continues, and that it's not superceded by network AI. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: David Culp [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 2:12 PM Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??) Without a scenario loaded, or a connection to a server, its just you all by your lonesome (which I had thought was the situation given my experience loading up FG and flying around with the default settings) The AI already in place is little used because it's tied to one airport and needs some generalizing. I'm looking forward to network flying, including network AI, but I hope development of local machine AI continues, and that it's not superceded by network AI. Thats why I'm approaching an AI/Scripting language the way I am. So it is useful for both net and local usage, and why I'm not so interested in doing a stand-alone server only implementation, but rather tying into the existing aircraft modeling system (wether that is the FDM or AIPlane model, or both most likely). There are far too many usage scenarios to sharply delimit what is client and what is server in my opinion. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
On 11/13/03 at 1:48 PM John Barrett wrote: Why is an interactive session by default generating AI aircraft without a loaded scenario to control those aircraft ?? The server should be loading the scenario. Having an airport spawn aircraft just because someone is close by the airport should not be a default behavior of the simulator. Similarly, if a client is acting as a adjunct to a server, it will need a scenario loaded from the command line, or provided by the server to control its spawning and behavior of AI planes. Without a scenario loaded, or a connection to a server, its just you all by your lonesome (which I had thought was the situation given my experience loading up FG and flying around with the default settings) Um, my plan was actually to have the sim spawn appropriate random aircraft as the user gets near, and to have each airport populated with statics which can randomly spawn into life. Is there anything wrong with this? Obviously the user should be able to switch this off, and it should be turned off automatically when the sim connects to a server. In the long run it should also be overridable if the user wants to drop in say a file of actual airline routes and times. (The GA stuff should still be random though). IMHO Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
John Barrett wrote: Why is an interactive session by default generating AI aircraft without a loaded scenario to control those aircraft ?? David Luff wrote: Um, my plan was actually to have the sim spawn appropriate random aircraft as the user gets near, and to have each airport populated with statics which can randomly spawn into life. Is there anything wrong with this? Maybe a more productive way to argue about architecture would be to concentrate on the toolbox functionality you *both* are going to need. :) Clearly you both want the ability to tell the system to load up a 747-400 model, position it at this location/orientation/velocity, and update as needed. You both want the ability to enumerate the active AI aircraft in the system, set up an interpolative path for the aircraft, etc... It may be that this will be all the code you two share. A massively multiplayer server will most likely prefer to have a global set of flight plans rather than auto-generating aircraft near the (potentially very large) player set. The server's approach to the same problem (too many AI aircraft for the client to handle) is going to revolve around deciding which of the thousands of AI aircraft to update on which clients at what time. Likewise, it probably won't want auto-generated aircraft polluting the skies around players. So long as you two don't share code at the top level, and instead are simply using the same foundations, you won't care. By analogy: hand two kids a box of legos and they can both play happily. Hand them the same blocks in the form of a space cruiser and you have a fight. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: Curtis L. Olson [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 3:34 PM Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??) John Barrett writes: Why is an interactive session by default generating AI aircraft without a loaded scenario to control those aircraft ?? The server should be loading the scenario. Having an airport spawn aircraft just because someone is close by the airport should not be a default behavior of the simulator. These are the sorts of things you might want/need if you are not connected to a MMP server ... as I understand it, the current focus of everything in the src/ATC/ directory is a stand alone fictitious environment not connected to any MP server. Similarly, if a client is acting as a adjunct to a server, it will need a scenario loaded from the command line, or provided by the server to control its spawning and behavior of AI planes. Without a scenario loaded, or a connection to a server, its just you all by your lonesome (which I had thought was the situation given my experience loading up FG and flying around with the default settings) I suppose we can divide the work up and draw the line any place we like. But my preference would be to control all the AI traffic in the server and not burden the core FlightGear code with it. Note that unless you are 100' away from an airplane, there is no way you are going to be able to tell if it's running real flight dynamics, or some ultra-simple non-physics based engine that just moves the airplane along some predetermined route. 99.% of the time in civilian aviation, you should never get that close to an airplane. Regards, Curt. I'll ask again -- why by default, why not under control of a loaded scenario which defines the planes and patterns -- then having ai planes is a question of did I load a scenario, even a generic one that states for any airport, when a plane gets close, spawn 3 planes doing touch-n-go circuits ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
Andy Ross writes: So long as you two don't share code at the top level, and instead are simply using the same foundations, you won't care. By analogy: hand two kids a box of legos and they can both play happily. Hand them the same blocks in the form of a space cruiser and you have a fight. :) My little brothers would always destroy my lego creations the instant I turned my back in order to build their own. Grrr ... :-) 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] ACScript RFC (or FGScript ??)
John Barrett writes: Why is an interactive session by default generating AI aircraft without a loaded scenario to control those aircraft ?? The server should be loading the scenario. Having an airport spawn aircraft just because someone is close by the airport should not be a default behavior of the simulator. These are the sorts of things you might want/need if you are not connected to a MMP server ... as I understand it, the current focus of everything in the src/ATC/ directory is a stand alone fictitious environment not connected to any MP server. Similarly, if a client is acting as a adjunct to a server, it will need a scenario loaded from the command line, or provided by the server to control its spawning and behavior of AI planes. Without a scenario loaded, or a connection to a server, its just you all by your lonesome (which I had thought was the situation given my experience loading up FG and flying around with the default settings) I suppose we can divide the work up and draw the line any place we like. But my preference would be to control all the AI traffic in the server and not burden the core FlightGear code with it. Note that unless you are 100' away from an airplane, there is no way you are going to be able to tell if it's running real flight dynamics, or some ultra-simple non-physics based engine that just moves the airplane along some predetermined route. 99.% of the time in civilian aviation, you should never get that close to an airplane. 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] ACScript RFC (or FGScript ??)
On 11/13/03 at 12:50 PM Andy Ross wrote: John Barrett wrote: Why is an interactive session by default generating AI aircraft without a loaded scenario to control those aircraft ?? David Luff wrote: Um, my plan was actually to have the sim spawn appropriate random aircraft as the user gets near, and to have each airport populated with statics which can randomly spawn into life. Is there anything wrong with this? Maybe a more productive way to argue about architecture would be to concentrate on the toolbox functionality you *both* are going to need. :) Nah, that's simply the most sensibly way. The most productive way is race you to get it finished ;-)) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Geo formulae
On Thursday, 13 November 2003 00:36, Norman Vine wrote: One way todo this is to always use the same size texture so as to be able to use glTexSubImage2D() to control the level of detail and mipmaping ourselves. Easiest todo this if the scenery is laid out so when you go to a lower level texture it covers 4 times the area and visa versa I object! :) That works great for textures that are tilable/repeatable but what about aerial/satelite photos? You don't want to stretch an aerial photo at all let alone over 4 times the area. Aerial photos can be mipmapped and loaded into video memory without a high res level but it's texture co-ords must still be tied to the same geographic co-ords, otherwise my 10 meter long hanger suddenly becomes 40 meters long and shifts a couple of kms from where it's meant to be. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
David Luff writes: Younger (still destructive) kid went to bed early the other night, so I got to play Lego (Duplo - the next size up bricks) with slightly older kid only. My wife seemed somewhat surprised to find a tower stretching from floor to ceiling when she got in, held in place at the top with blue-tack. Apparently this isn't normal behaviour... My 2 year old daughter got her second duplo set last Christmas (actually before she turned two.) Duplo's are great for towers because the larger block size let's you build big stuff much faster. We've made some wonderfully tall towers here, and my daughter loves to knock them down (usually in mid-construction.) Like you say, us adults have to wait until after bed-time before we can get a good shot at playing with our kids toys. I will assert that this is normal behavior, it's just mostly everyone else that is strange. :-) 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] ACScript RFC (or FGScript ??)
On 11/13/03 at 2:53 PM Curtis L. Olson wrote: My little brothers would always destroy my lego creations the instant I turned my back in order to build their own. Grrr ... :-) Younger (still destructive) kid went to bed early the other night, so I got to play Lego (Duplo - the next size up bricks) with slightly older kid only. My wife seemed somewhat surprised to find a tower stretching from floor to ceiling when she got in, held in place at the top with blue-tack. Apparently this isn't normal behaviour... Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Scenery engine features.
I'm sure this subject has been brought up plenty of times but I think it would be great to compile a list of all the features that we need the FG terrain rendering system to support. I want to keep this to features only - lets forget about the implementation for the moment so we can at least get everyone's ideas down without having 50 emails of it can't be done like this or must be done like that. Let's make a comprehensive list first and then discuss the HOWTO's afterwards. Maybe we can even come up with a roadmap!!! :-P My list : 1. LOD algorithm/system (with adjustable radius for high and low end users) The current irregular grid mesh works but it's not very efficient and we could get much better framerates with a nice LOD system. Alternatively much higher elevation resolution with similar framerates. 2. Texture overlays - FG scenery engine does the chopping and texture co-ord generation. (I won't go into details but this would greatly simplify LOD algorithms) Your list : Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery engine features.
Paul Surgeon writes: I'm sure this subject has been brought up plenty of times but I think it would be great to compile a list of all the features that we need the FG terrain rendering system to support. I want to keep this to features only - lets forget about the implementation for the moment so we can at least get everyone's ideas down without having 50 emails of it can't be done like this or must be done like that. Let's make a comprehensive list first and then discuss the HOWTO's afterwards. Maybe we can even come up with a roadmap!!! :-P My list : 1. LOD algorithm/system (with adjustable radius for high and low end users) The current irregular grid mesh works but it's not very efficient and we could get much better framerates with a nice LOD system. Alternatively much higher elevation resolution with similar framerates. 2. Texture overlays - FG scenery engine does the chopping and texture co-ord generation. (I won't go into details but this would greatly simplify LOD algorithms) Your list : I'll add in a few things: - Ability to cut in polygon models of airports. - Ability to page terrain / textures so continuous flights around the world are still possible. - Ability to populate the world with arbitrary additional 3d objects. Note that our current ability to populate the world with random objects would not work with the new scheme. We'd need to completely overhaul that functionality to work in a photo texture drapped, LOD terrain world. - Care should be taken with object vertical placement so the terrain LOD doesn't move the 3d objects up and down noticable. And also so it doesn't noticably bury objects or float objects when the terrain LOD changes. - I assume all the current 2d polygon data would go away since this would be better represented by the photo texture overlay anyway. I bet we'll run into other things, but if you are serious about making a stab at this, then I will propose that we a) find a way to do it in parallel to the current system and b) just jump in and start going. I don't think it's realistic to have your first pass encapsulate *all* current functionality of the scenery subsystem. And there will most likely be things we don't consider until we get hit over the head with it. I can think of different situations where each approach would be more optimal than the other, so it probably wouldn't hurt to have more than one way to do things. Best 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] Geo formulae
Paul Surgeon writes: On Thursday, 13 November 2003 00:36, Norman Vine wrote: One way todo this is to always use the same size texture so as to be able to use glTexSubImage2D() to control the level of detail and mipmaping ourselves. Easiest todo this if the scenery is laid out so when you go to a lower level texture it covers 4 times the area and visa versa I object! :) That works great for textures that are tilable/repeatable but what about aerial/satelite photos? You don't want to stretch an aerial photo at all let alone over 4 times the area. Aerial photos can be mipmapped and loaded into video memory without a high res level but it's texture co-ords must still be tied to the same geographic co-ords, otherwise my 10 meter long hanger suddenly becomes 40 meters long and shifts a couple of kms from where it's meant to be. No problem the LOD image that you load is a composite of the subsampled mosaic of the 4 higher res images.. The hanger keeps getting half as large tied to the same spot until it disapears. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Scenery engine features.
Curtis L. Olson writes: Paul Surgeon writes: I'm sure this subject has been brought up plenty of times but I think it would be great to compile a list of all the features that we need the FG terrain rendering system to support. I'll add in a few things: me too - Ability to cut in polygon models of airports. Any cut in polygons respect tile boundaries i.e a polygon can only be in one tile - Ability to page terrain / textures so continuous flights around the world are still possible. :-) - Ability to populate the world with arbitrary additional 3d objects. Note that our current ability to populate the world with random objects would not work with the new scheme. We'd need to completely overhaul that functionality to work in a photo texture drapped, LOD terrain world. I think we could make the current scheme work as the only thing changing will be the local 'Z' and height calculations would be *much* simpler - Care should be taken with object vertical placement so the terrain LOD doesn't move the 3d objects up and down noticable. And also so it doesn't noticably bury objects or float objects when the terrain LOD changes. - I assume all the current 2d polygon data would go away since this would be better represented by the photo texture overlay anyway. We still need polygons to shape the terrain for roads, rivers etc. during scenery creation and then there are the airports. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [BUGS] Navaids/default.nav.gz, Airports/{basic, runways}.dat.gz, ...
* Melchior FRANZ -- Monday 03 November 2003 08:36: The first bug is quite old and was already reported a few times, the second is a cosmetic problem, while the third is more than a cosmetic problem: [...] Could somebody please fix this? m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery engine features.
On 11/14/03 at 12:17 AM Paul Surgeon wrote: I'm sure this subject has been brought up plenty of times but I think it would be great to compile a list of all the features that we need the FG terrain rendering system to support. I want to keep this to features only - lets forget about the implementation for the moment so we can at least get everyone's ideas down without having 50 emails of it can't be done like this or must be done like that. Let's make a comprehensive list first and then discuss the HOWTO's afterwards. Maybe we can even come up with a roadmap!!! :-P My list : 1. LOD algorithm/system (with adjustable radius for high and low end users) The current irregular grid mesh works but it's not very efficient and we could get much better framerates with a nice LOD system. Alternatively much higher elevation resolution with similar framerates. 2. Texture overlays - FG scenery engine does the chopping and texture co-ord generation. (I won't go into details but this would greatly simplify LOD algorithms) Your list : The ability to drape the textures at differing resolutions at different locations in the scenery. (ie. higher res data immediately adjacent to airports where the pilot is generally closer to the ground and to give good definition on final approach). Some sort of fix or workaround for the stretched-textures-on-cliff faces problem that draped textures suffer from in mountainous regions - possibly the ability to cut in textured polygons on steep faces. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-users] My screen shot.
On Thu, 2003-11-13 at 07:55, Andy Ross wrote: Norman Vine wrote: Somethng like this is easy enough to implement with the current hitlist code but ... I don't understand why the compressability of the gear has any bearing on the point of contact. It is the AC that is changing not the Terrain Gear don't always compress perpendicular to the ground, and not all aircraft contact points are landing gear. Wing tips, for example, might hit the ground at funny angles or hit terrain objects like buildings that aren't flat. But they won't compress at all until contact, at which time the point of contact is known. The location of ground contact (and thus the point of force application on the aircraft) is going to be somewhere on the line between the point of maximum gear compression and maximum gear extension. Where? At the point where this line segment interects the terrain polygons. (Strictly, at the intersection nearest the max compression point if there is more than one). Why wouldn't the gear always contact the ground at max extension? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Scenery engine features.
Paul Surgeon writes: I'm sure this subject has been brought up plenty of times but I think it would be great to compile a list of all the features that we need the FG terrain rendering system to support. Norman Vine writes: - Ability to cut in polygon models of airports. Any cut in polygons respect tile boundaries i.e a polygon can only be in one tile It's easy to chop up polygons on tile boundaries, but you are probably referring to airport areas. :-) - Ability to page terrain / textures so continuous flights around the world are still possible. :-) I only say this because I've seen a lot of ROAM type demos that look cool for a small area, but I get the sense that it's a bit trickier to build an entire seamless earth. It's probably been done in commercial games (?) but I haven't seen this done in the open souce world. Just a word of advice ... if you are building a scheme and run across some oversite and are tempted to think, what are the chances of seeing this case in real life. Believe me, when you throw all the data of the world at your scheme, you'll see it a lot more than you expected. :-) Modeling the entire world is a good way to keep yourself honest. :-) I think we could make the current scheme work as the only thing changing will be the local 'Z' and height calculations would be *much* simpler We have to be careful though of objects floating up and down noticable as the underlying terrain LOD changes. We still need polygons to shape the terrain for roads, rivers etc. during scenery creation and then there are the airports. My understanding is that roads, rivers, lakes, cities, etc. (all that stuff we handle with 2d polygons right now) could be embedded in the aerial photos / textures that we are draping over the terrain, so there would be no need to cut them in as polygons. Airports are a bit different though ... unless we have *really* high res data as in less than 1 foot per pixel, we'll want to still model this polygonally. The San Jose demo was interesting, but it still needed better resolution. Just one airport area could easily consume a Gb of texture ram if we wanted to use a nice resolution. But that still wouldn't address all the squashed buildings, and all the nice aircraft painted on the runways in various stages of taxiing, landing, and taking off. Also, you get everything shaded from one particular time of day. There are tradeoff's to every approach. :-) 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
[Flightgear-devel] Who is John Ridouts?
Hello list, Basically more for info and speculation than anything else. I've just received an e-mail from a 'John Ridouts' that consists of nothing but an attachment titled '~WRD0564.scr' The reason I mention it here is that it was also addressed to a number of people I recognise from this place. The oddest thing about it is that I got two copies, addressed to two different addresses that I don't actually use here. When I originally signed on to the FG mailing lists I intended to use a unique name, just for FG stuff, so I could track it's spread more easily. However, I kept forgetting to send with the name I'd specified and the e-mails got bounced. Infact I did this twice, hence the two different IDs, before I decided it would be easier all round if I just used my 'normal' one. Well, the two e-mails were addressed to the two IDs that I now never use, and haven't used since my first couple of posts, both here, on the fdm and user lists. Funnily enough, I haven't recieved one to the ID I do now use:-/ Over the past few months or so, I've also received a few spams to these IDs as well but again, not to my 'live' ID. The e-mail addresses could be harvested from a number of places but it's curious that the data that was obtained was so old and didn't include my current ID. As I mentioned, I've received some spam to the IDs but this looks more like a virus because of the .scr attachment. I haven't checked the virus lists yet though. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel