Re: [Flightgear-devel] Today's CVS
Hi Vivian, On Friday 06 July 2007 23:31, Vivian Meazza wrote: After further testing I can confirm that the disappearance is readily repeatable. If you position your ac on the threshold of 28R at KSFO, as the AI aircraft are about to trample all over you they obligingly commit suicide. The first then reappears well down runway 28L taking off, the second just disappears. This I can replicate! I was unable to reproduce this, until you provided a vital clue in the current message: as they are about to trample all over you. I usually try to get off the runway ASAP using the UFO, when inspecting traffic behavior, so I missed this one completely. Initially, I was a little confused about the teleporting part of your bug report, but it makes sense now. You couldn't know, but the disappearing and respawning are two independent phenomena. There is some basic proximity detection code which cause AI aircraft to wait for the user's aircraft. More recently I added a new function that detects situations in the ground network were aircraft are eventually waiting for themselves. (i.e. a waits for b; b waits for c; but c waits for a). The occurrence of these is not frequent, but when it happens, the waiting aircraft can block all other traffic. Eventually, this needs to be resolved more gracefully, probably by moving one of the offending aircraft back, or by implementing more sophisticated hold position instructions. Until that time the offending aircraft are removed from the scene. It seems this function is triggered whenever an AI aircraft is waiting for the user. I believe a solution is fairly straightforward, but requires some more testing. I'll probably have something at the end of the day. The respawning on the other hand, is a different phenomenon. During initialization, the traffic manager makes an estimate as to which stage of a flight an aircraft is: Wait at gate / push back / taxi / take off / climb / cruise. When an aircraft is considered to be in the take off stage, it is placed on the runway, and given take off speed during initialization, thus creating the illusion of a spontaneous spawning of these aircraft. It's not really an ideal situation, waiting for refinement. FWIW, I also hope to have a look at the tanker speeds this weekend. Cheers, Durk - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Apply throttle axis changes only to selected engines
* Anders Gidenstam -- Saturday 07 July 2007:
In my work on LZ-129 Hindenburg I discovered that I need to be able
to quickly control the engines individually or in (sub)groups
I've thought in the past that the throttle should really respect
the selected engines.
1. throttleMouse(), throttleAxis() and incThrottle() only change the
throttle setting for the selected engines, i.e. those that have
/sim/input/selected/engine[i] == true
You shouldn't have things in the loop that don't change, though
it's certainly not a big performance problem. For example the
cmdarg().getNode(offset).getValue() * -4.
This code sets the same value for all selected engines to the js/mouse
value. But if they weren't all at the same level, this would mean that
some make abrupt jumps. Applying the same delta to all selected engines
would be nicer, but has its own problems ... :-/
2. A new function controls.selectEngineToo(e_no) adds engine number e_no
to the set of active engines. The existing selectEngine() is mutually
exclusive - it deselects all other engines.
I'd rather make a function something like this:
var selectEngines = func(state, engines...) {
var sel = props.globals.getNode(/sim/input/selected);
if(size(engines)) {
foreach(var e; engines)
sel.getChild(engine, e, 1).setBoolValue(state);
} else {
foreach(var e; sel.getChildren(engine))
e.setBoolValue(state);
}
}
One could then say
selectEngines(1);# select all engines
selectEngines(0);# unselect all engines
selectEngines(1, 3, 5, 7); # select engines 3, 5, and 7
selectEngines(0, 4); # unselect engine 4
That is: the first argument decides whether to select or unselect,
followed by a list of engine indices, to which the operation applies
(for example, all engines on the left of an airship). If no engines
are listed, then all of them are used. (Maybe a bit overengineered. ;-)
m.
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Today's CVS
Durk Talsma Sent: 07 July 2007 08:22 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Today's CVS Hi Vivian, On Friday 06 July 2007 23:31, Vivian Meazza wrote: After further testing I can confirm that the disappearance is readily repeatable. If you position your ac on the threshold of 28R at KSFO, as the AI aircraft are about to trample all over you they obligingly commit suicide. The first then reappears well down runway 28L taking off, the second just disappears. This I can replicate! I was unable to reproduce this, until you provided a vital clue in the current message: as they are about to trample all over you. I usually try to get off the runway ASAP using the UFO, when inspecting traffic behavior, so I missed this one completely. Initially, I was a little confused about the teleporting part of your bug report, but it makes sense now. You couldn't know, but the disappearing and respawning are two independent phenomena. There is some basic proximity detection code which cause AI aircraft to wait for the user's aircraft. More recently I added a new function that detects situations in the ground network were aircraft are eventually waiting for themselves. (i.e. a waits for b; b waits for c; but c waits for a). The occurrence of these is not frequent, but when it happens, the waiting aircraft can block all other traffic. Eventually, this needs to be resolved more gracefully, probably by moving one of the offending aircraft back, or by implementing more sophisticated hold position instructions. Until that time the offending aircraft are removed from the scene. It seems this function is triggered whenever an AI aircraft is waiting for the user. I believe a solution is fairly straightforward, but requires some more testing. I'll probably have something at the end of the day. The respawning on the other hand, is a different phenomenon. During initialization, the traffic manager makes an estimate as to which stage of a flight an aircraft is: Wait at gate / push back / taxi / take off / climb / cruise. When an aircraft is considered to be in the take off stage, it is placed on the runway, and given take off speed during initialization, thus creating the illusion of a spontaneous spawning of these aircraft. It's not really an ideal situation, waiting for refinement. OK so it's 2 features, not 1 bug - excellent. I also noted that the route taken from parking to active runway seemed a bit odd, but then I compared our taxiways to those on Google Earth - we seem to have bits missing alongside 28L, which explains that. Not good for our default airport though. FWIW, I also hope to have a look at the tanker speeds this weekend. Your proposed fix seems to work here, on the basis of just one test, I haven't had time to do the job properly. Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Today's CVS
On Saturday 07 July 2007 09:41, Vivian Meazza wrote: OK so it's 2 features, not 1 bug - excellent. I also noted that the route taken from parking to active runway seemed a bit odd, but then I compared our taxiways to those on Google Earth - we seem to have bits missing alongside 28L, which explains that. Not good for our default airport though. Well, the disappearance is a bug, caused by a feature that is a little too trigger happy right now. I will also try and add a few more taxiways. FWIW, I also hope to have a look at the tanker speeds this weekend. Your proposed fix seems to work here, on the basis of just one test, I haven't had time to do the job properly. Okay thanks. Will test a bit, and hopefully commit tonight. D. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh? (especially addressing Harald Johnsen)
Georg Vollnhals schrieb: Sebastian Bechtold schrieb: .. If possible, I'd like to try to do this without doing such further changes. I'd like to avoid a plan where one feature requires another, and this one requires another again, and so on. The more you change, the higher is the risk of unplanned side effects and work to adapt other things to the changes. As I've already said: For myself, some kind of golden rule here is to change as little of the existing concepts and code as possible. This may rise problems which require some odd and maybe suboptimal solutions, but I think that's still better than running into a situation where the list of things which have to be changed is growing longer and longer. ... Hi Sebastian, once again my suggestion would be in accordance to your point of view a) to _minimize all changes to the actual given code _b) doing all work and calculation *off* runtime . Then it should be possible to 1. have the lat/lon coordinates calculated for all 4 corners of the used _new texture_ of any size 2. calculate the lat/lon coordinates of every corner of every _triangle_ out of the *.btg file and sort the tiles (the fileformat is sure documented anywhere, I looked for it but did not find any documentation) I hope/think that I don't have to care about the .btg file format. I would like to plug my stuff into the code somewhere downstream from the point where the terrain is loaded from the .btg file, and ignore how and from where it is loaded. When the triangles are instantiated in the scene graph, it must be possible to get the world coordinates of their vertices and apply the textures based on this information. 3. split the new texture into the sizes of all given triangles using the precalculated triangles area/lat-lat-corners Well, no. You wouldn't split up the textures. First, it's not possible (as far as I know, textures are always rectangular, I have never heard of triangular textures. Correct me if I'm wrong). Second, there's no reason to do so. You simply work with big textures that cover many triangles, and you do this by telling your 3D engine which area of the big texture should be mapped onto which triangle. This is not specific to my plan, it's the standard solution (I'm pretty sure you know this from Blender). 3.a uncomplicated for all triangles fully located within the new texture area = only new texture is used 3.b more problematic for boarder triangles only partly located within the new texture area = merging of old ground texture for the outside part and new texture for the inside part has to be done. This would be one theoretically possible solution to handle the irregular triangulation problem (see the conversation with Harald Johnsen). Practically, I think it would be very complicated. In my concept, the texture generation process knows nothing about the underlying and surrounding triangulation and texturing of the terrain at the place where a certain texture tile will be mapped. So you don't know when, where and how you'd have to do this texture merging. The two methods discussed with Harald Johnsen are probably better ways to go. 4. this results in a special ground-texture for every given triangle 5. there must be already a marker in the actual *.btg format for every ground-triangle which ground-texture to use. But there is only a limited number of ground-textures and therefore the marker might not have the data-format for a *big* number of different ground-textures (what would be necessary if we split bigger textures and create a lot of different new ground-textures). So a slight change of the *.btg format might be necessary. 6. With this the actual display-routines for OSG and PLIB should work principally, only the new *.btg data-format (for the really bigger number of available ground-textures) must be handled Well, as explained above and also noticed by yourself here: There's no one triangle - one texture-association, and we don't need or want it. You can happily forget points 4 to 6 :). _I know, this solution is suboptimal but can be made with a overviewable amount of coding_ (and therefore the chance to have very little negative sideeffects) but makes a big ground-texture improvement possible. And I know that this can really get more complicated if the new ground-texture-area uses partly 2 or more *.btg files. As far as I know, each .btg file contains a number of complete tiles, and the border of a scenery described in one .btg files consists of the borders of the tiles in the border area. When we map one texture on one tile (or several textures on one tile, but no texture across several tiles), there should be no problem here. Once working pretty well, this changes could be improved more and more in little further steps - that is what everyone likes to avoid big coding-problems. Some years ago I did this for X-Plane with own new groundtextures
Re: [Flightgear-devel] Today's CVS
On Saturday 07 July 2007 09:46, Durk Talsma wrote: On Saturday 07 July 2007 09:41, Vivian Meazza wrote: OK so it's 2 features, not 1 bug - excellent. I also noted that the route taken from parking to active runway seemed a bit odd, but then I compared our taxiways to those on Google Earth - we seem to have bits missing alongside 28L, which explains that. Not good for our default airport though. Well, the disappearance is a bug, caused by a feature that is a little too trigger happy right now. Actually, this is what happens. While I work on a solution: Have some fun with it: Make a left turn onto the taxiway, and taxi toward oncoming traffic. You see they'll be zapped away as you appoach them. :-) Cheers, Durk - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Apply throttle axis changes only to selected engines
On Sat, 7 Jul 2007, Melchior FRANZ wrote:
This code sets the same value for all selected engines to the js/mouse
value. But if they weren't all at the same level, this would mean that
some make abrupt jumps. Applying the same delta to all selected engines
would be nicer, but has its own problems ... :-/
Actually, throttleMouse applies a delta while throttleAxis sets an
absolute value (unless I misread the code). That behaviour at least makes
some kind of sense.. :)
I'd rather make a function something like this:
var selectEngines = func(state, engines...) {
...
}
Ah, yes that is much nicer. I hadn't grasped the argument list
possibility. Thanks for the code review!
Updated diff:
http://www.gidenstam.org/FlightGear/misc/controls.nas_individual_throttles.diff
Cheers,
Anders
--
---
Anders Gidenstam
mail: anders(at)gidenstam.org
WWW: http://www.gidenstam.org/FlightGear/JSBSim-LTA/
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Today's CVS
Am Samstag 07 Juli 2007 09:41 schrieb Vivian Meazza: OK so it's 2 features, not 1 bug - excellent. I also noted that the route taken from parking to active runway seemed a bit odd, but then I compared our taxiways to those on Google Earth - we seem to have bits missing alongside 28L, which explains that. Not good for our default airport though. The route finding is extremely simple. It just calculates the shortest way between 2 points (in terms of travel distance) of the ground network. The ground network is a directed graph though. Probably there are some invisible one-ways in it. It might be possible to make the way finding more clever (e.g. penalize runway crossings etc.), but this would need a more sophisticated groundnet, with more node types (i.e. holding positions) than now. Which might be a good idea anyway. Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Today's CVS
On Saturday 07 July 2007 11:16, Thomas Förster wrote: Am Samstag 07 Juli 2007 09:41 schrieb Vivian Meazza: OK so it's 2 features, not 1 bug - excellent. I also noted that the route taken from parking to active runway seemed a bit odd, but then I compared our taxiways to those on Google Earth - we seem to have bits missing alongside 28L, which explains that. Not good for our default airport though. The route finding is extremely simple. It just calculates the shortest way between 2 points (in terms of travel distance) of the ground network. The ground network is a directed graph though. Probably there are some invisible one-ways in it. I just checked using taxidraw. There are some taxiroutes missing, thus preventing traffic to follow the shortest route. I'm working on it. It might be possible to make the way finding more clever (e.g. penalize runway crossings etc.), but this would need a more sophisticated groundnet, with more node types (i.e. holding positions) than now. Which might be a good idea anyway. Eventually, that would be the plan. Before we can do this, we need to have more sophistcation in the ground network, and consequently, also in it's principal design tool; taxidraw. Part of that is going to be my summer / fall project. Cheers, Durk - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh? (especially addressing Harald Johnsen)
Sebastian Bechtold schrieb: Georg Vollnhals schrieb: ... Second, if we save these auto-generated textures on the hard disk (what should generally be a good idea for performance reasons), you could load them into an image manipulation program and add your own stuff or, for example, replace the auto-generated images with real aerial photos (if you have them and you're allowed to use them for FlightGear). In other words, you could paint anything anywhere. There are endless possibilities, if only the texture resolution is high enough. Ok, I'll wait and see :-) Almost everything will be better than the actual state. With best regards, Sebastian PS.: Did you try my patch? Well, I had a lot of workload at the end of last week as I worked some days from 7:00 am to sunset around 10:00 pm. So there was not so much time for FlightGear. Sometimes I am able to look at the forum or eMail, but I have no FG to do any work with (I only have a very old and poor performing laptop :-/ ). This whole weekend I am working on call (and just came back home) and if my mobile phone is quite for some hours I would like to compile and test your nice patch. Of course, I will give feedback to you, as I am really interested in this feature :-) Thank you once again for explaining me what you would like to do. Regards Georg - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] CVS Server problems
Hi all, a 'cvs update' failed for me today: can't create temporary directory /tmp/cvs-serv9314 No space left on device As my local /tmp has plenty of space left (2GB) I suspect the CVS server to be the culprit. Anyone here who can change that? Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flight control polarity
On 07/07/2007 05:16 AM, Gordan Sikic wrote: Dear John, I didn't have any intention to start any quarrellings with you. Being open minded, I've just asked you to share your literature with us, and I don't understand why you feel so pissed off. Why do you think I am pissed at you? AFAICT there's not even a question about polarity, let alone a pissy question. If you really do not have any literature to share with us, just say (write) so. 1) I am traveling right now. I am away from my books. But I remain confident that the books say what I said they say. 2) There was one brief misunderstanding, but I thought that was cleared up with help of Jon Berndt, so I thought there was no need for literature or for additional clarification. 3) I consider this misunderstanding trivial, because the ideas and the code remain the same; only the wording of my explanation needed to change. 4) I have already apologized once for this brief and superficial misunderstanding. What more do I need to do? Aircraft control and simulation, by Brian Stevens and Frank Lewis, on page 128, there is a table (TABLE 3.3.1), where is clearly stated that positive movements of all primary control surfaces produce negative moments. 1) As Jon B. pointed out, I intended to talk about cockpit control deflections, not physical aerosurface deflections. I'm a pilot and flight instructor, and I sometimes lapse into pilot-speak without realizing it. I thought it was obvious from context that I was talking about cockpit controls and cockpit indicators, but I gather it wasn't sufficiently obvious. Sorry. 2) The fact remains that FG does not consistently follow either convention. My patch makes it possible to present a consistent convention to the pilot. If this does not address the point you were making, please re-ask the question. Note that the FG properties /controls/flight/rudder /controls/flight/elevator /controls/flight/aileron pertain to cockpit controls, not to control surfaces directly. If anybody thinks that these properties are conventional as to polarity, please say so. I have not yet heard anyone say that they are. Unless/until I hear that there actually is a issue here, I will assume there is no issue, and no need for me to cite literature or say anything more. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS Server problems
On Saturday 07 July 2007 12:17, Durk Talsma wrote: On Saturday 07 July 2007 12:14, Thomas Förster wrote: can't create temporary directory /tmp/cvs-serv9314 No space left on device As my local /tmp has plenty of space left (2GB) I suspect the CVS server to be the culprit. Anyone here who can change that? Thomas Same thing here. Seems like a server problem. Probably Curt is the only person who can fix that. Okay, Curt mailed me that it's fixed again, and I can confirm. Cheers, Durk - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Today's CVS
On Saturday 07 July 2007 10:03, Durk Talsma wrote: On Saturday 07 July 2007 09:41, Vivian Meazza wrote: .. compared our taxiways to those on Google Earth - we seem to have bits missing alongside 28L, which explains that. Not good for our default airport though. Okay, fixed as of a minute ago. :-) Well, the disappearance is a bug, caused by a feature that is a little too trigger happy right now. Actually, this is what happens. While I work on a solution: Have some fun with it: Make a left turn onto the taxiway, and taxi toward oncoming traffic. You see they'll be zapped away as you appoach them. :-) Okay, play time is over. :-) The trigger happy function is fixed. Cheers, Durk - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random instrument failures and altimeter gremlins patch
--- Melchior FRANZ wrote:
* Stuart Buchanan -- Tuesday 03 July 2007:
The included XML files replace those in the gui/dialogs directory,
while
gremlins.nas should be put in the Nasal directory.
gremlins.nas? Please not funny names in $FG_ROOT/Nasal/. These
are code files, and so far all of them were called after their purpose.
This makes it easier for all to see what they are about.
What I don't really understand is why local variables need to be ii and
nnn. What's wrong with just i and n, like everyone else uses? Or is
exactly *that* the problem?
for (ii = 0; ii 5; ii+=1){
...
nnn = props.globals.getNode(feat ~ /serviceable, 1);
if (nnn.getValue() == nil) {
nnn.setBoolValue(1);
I've fixed both these issues. The Nasal file is now called failures.nas,
and I've shortened the variables as requested. I've also gotten rid of the
height and width settings on the dialog boxes.
New version of the patch, along with documentation available from
http://www.nanjika.co.uk/flightgear/failures.tar.gz
Could someone please commit this to CVS?
Best Regards to all,
-Stuart
___
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] improved HSI ADF(RMI) : double-shafted needle
Hi -- This pertains to the HSI instrument as used in the c182, c182rg, and many other GA aircraft models. The FG HSI instrument now has a double-shafted ADF(RMI) needle, as shown here: http://www.av8n.com/fly/fgfs/RMI.jpg which is more nearly like a real-world HSI/ADF(RMI). In contrast, heretofore on the model HSI, the tip of the ADF (RMI) needle looked a whole lot like the tip of the VOR needle. This made it much too easy for the pilot to follow the wrong needle. This may seem like a small thing, but if you're trying to simulate real IFR flying, small things like this can make a big difference. This change affects the following files: Aircraft/Instruments/Textures/hsi.rgb Aircraft/Instruments/hsi.xml This has been committed to the _Sport Model_. For a list of the main features of the _Sport Model_, see http://www.av8n.com/fly/fgfs/README.sport.model For details on how to download the _Sport Model_, see http://www.av8n.com/fly/fgfs/git-overview - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] patch, plib-branch, directional sound
* Maik Justus -- Tuesday 03 July 2007: here is the patch for the directional sound and correct Doppler sound (and stereo sound) for the plib branch. Committed. Well, actually I have missed this patch and first committed the one from Sun, 01 Jul 2007, but then committed the rest. I hope I din't mess anything up. Please check. All files in the sg/sound dir are tagged before and after the changes with (BEFORE|AFTER)_OPENAL_WORKAROUND so that one can easier see what the regular version is, and what had to be added because of the OpenAL bug. For removing this should be enough: $ cd simgear/sound $ cvs diff -rAFTER_OPENAL_WORKAROUND -rBEFORE_OPENAL_WORKAROUND|patch $ cvs ci m. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] improved HSI ADF(RMI) : double-shafted needle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Denker wrote: Hi -- This pertains to the HSI instrument as used in the c182, c182rg, and many other GA aircraft models. ... This has been committed to the _Sport Model_. For a list of the main features of the _Sport Model_, see http://www.av8n.com/fly/fgfs/README.sport.model For details on how to download the _Sport Model_, see http://www.av8n.com/fly/fgfs/git-overview I think it's great that you're using git and and hope that we can reconcile pigeon's split SimGear / FlightGear git repo, which is a bit of a pain but updated automatically from CVS, with your more unified setup. In the long term I hope the FlightGear project will adopt git as a replacement for CVS. However, for now I think it would be best to include the diffs from your patches in these emails rather than pointing folks to your git repo. That will increase the chances of developers -- who might not yet be so keen on git -- looking at the patches and committing them, and give those of us who are using git too the option of applying your patches directly instead of fetching your sport model branch. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGkAndeDhWHdXrDRURAnS+AKCRrHkLvMGvYH+HVJcPLV2o569l6ACgpiD8 gsRVJL8sO0RlzVkDoDy31iM= =irKC -END PGP SIGNATURE- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] patches, patches
On 07/07/2007 05:47 PM, Tim Moore wrote: I think it's great that you're using git It's a nifty thing. and and hope that we can reconcile pigeon's split SimGear / FlightGear git repo, which is a bit of a pain but updated automatically from CVS, with your more unified setup. In the long term I hope the FlightGear project will adopt git as a replacement for CVS. Yeah. CVS has a rather narrow view of how the world should work, and FG doesn't really work that way. However, for now I think it would be best to include the diffs from your patches in these emails rather than pointing folks to your git repo. I customarily include the diffs, whenever that makes sense ... but it doesn't always make sense. a) Note that in this case, I'm modifying a binary file. It's hard to submit a meaningful diff of that, for reasons having nothing to do me or my work. b) See below. That will increase the chances of developers ... looking at the patches and committing them, Well, the chances certainly can't go down. I'm told that none of the active committers have any interest in the stuff I've been working on. There is such a backlog of patches that haven't even been looked at, let alone committed, that a diff against the CVS version is several times longer than the diff that just deals with the features I implemented this morning. The Sport Model is self-consistent, but it's not entirely a mixmatch à la carte proposition. In this case in particular, A) If I just diff this morning's work against its immediate ancestor, you won't be able to apply the patch, because the ancestor is several patches removed from the stock CVS branch. B) If I diff the current Sport Model hsi.xml against the stock CVS version, you can apply the patch, but you can't use the result, because it depends on extensions to hsi.cxx, among other dependencies. C) et cetera. The origin branch (i.e. the stock CVS model) works, and the Sport Model works, but we can't make the all the mixmatch chimeras work. It would be nice if we could, but we can't. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] yasim jet engine...
Hi all , Does any know if it's possible to add a condition lever check to the Yasim jet engine to simulate shutdown / engine failure ? Just the idle state would be sufficient , as long as throttles have no effect ... I tried some modifying of my own , but haven't sorted it all out yet ... Thanks -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Weekly CVS Changelog Summary: SimGear
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-02_07:55:21 (mfranz) /var/cvs/SimGear-0.3/source/simgear/debug/logstream.hxx add SG_ORIGIN macro that expands to a string __FILE__:__LINE__ Note that __LINE__ is a number and can't be directly used in string context, which makes the macro worthwhile. (IMHO :-) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-02_10:42:20 (mfranz) /var/cvs/SimGear-0.3/source/simgear/timing/lowleveltime.cxx replace exit() by throw sg_exception(). Of course, we have to be aware that interdependencies between sg libs are generally unwelcome, but sg_exception is a rather basic part, and it's already used by xml, props, scene, sound and, of course, structure. Since props and xml are core libs, we can assume that sg_exceptions are available. (OK'ed by Curt) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-02_10:42:21 (mfranz) /var/cvs/SimGear-0.3/source/simgear/timing/timezone.cxx replace exit() by throw sg_exception(). Of course, we have to be aware that interdependencies between sg libs are generally unwelcome, but sg_exception is a rather basic part, and it's already used by xml, props, scene, sound and, of course, structure. Since props and xml are core libs, we can assume that sg_exceptions are available. (OK'ed by Curt) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-02_14:57:15 (mfranz) /var/cvs/SimGear-0.3/source/simgear/scene/tgdb/Attic/leaf.cxx replace exit() by throw. Leaving the SG_LOG message in, because I observed unexpected problems with throwing exceptions from sg. :-/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-02_15:02:23 (mfranz) /var/cvs/SimGear-0.3/source/simgear/ephemeris/stardata.cxx s/exit(.*)/throw/ .. again leaving the SG_LOG in until I know why exceptions dont' work through static sg libs =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-02_15:06:04 (mfranz) /var/cvs/SimGear-0.3/source/simgear/ephemeris/stardata.cxx nope, return false is better here, sorry =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-07_13:37:58 (mfranz) /var/cvs/SimGear-0.3/source/simgear/sound/sample_openal.cxx /var/cvs/SimGear-0.3/source/simgear/sound/sample_openal.hxx /var/cvs/SimGear-0.3/source/simgear/sound/soundmgr_openal.cxx /var/cvs/SimGear-0.3/source/simgear/sound/soundmgr_openal.hxx /var/cvs/SimGear-0.3/source/simgear/sound/xmlsound.cxx Maik JUSTUS: [...] switches of the Doppler calculation of OpenAL and adds a own Doppler calculation. mf: necessary because OpenAL Doppler on Windows is broken, which the openal developers acknowledge. The source revisions before and after the patch was applied are tagged with BEFORE_OPENAL_WORKAROUND and AFTER_OPENAL_WORKAROUND, so that one can easier find and remove the changes if required (which is quite unlikely. :-) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-07_13:50:01 (mfranz) /var/cvs/SimGear-0.3/source/simgear/sound/sample_openal.cxx /var/cvs/SimGear-0.3/source/simgear/sound/xmlsound.cxx change sign initialize direction (this was in a later patch that I had missed) 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Weekly CVS Changelog Summary: FlightGear source
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-01_06:07:56 (mfranz) /var/cvs/FlightGear-0.9/source/src/Scripting/NasalSys.cxx - fix carttogeod() function (don't convert the altitude from radian to degree ;-) - better argument check in parsexml() =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-02_09:32:28 (mfranz) /var/cvs/FlightGear-0.9/source/src/GUI/gui_funcs.cxx - allow multiple message/error dialogs - hand the generation of the message dialog over to $FG_ROOT/gui/dialogs/message.xml =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-03_00:47:01 (mfranz) /var/cvs/FlightGear-0.9/source/src/Main/fg_props.cxx John DENKER: don't grow /sim/logging/classes indefinitely on read-out =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-03_10:35:57 (mfranz) /var/cvs/FlightGear-0.9/source/src/GUI/gui_funcs.cxx - limit max number of messages displayed at the same time to 5 (Ideally, it should be just one, but we don't want to block everything and don't want to miss messages either.) - prevent message duplicates =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-03_10:41:01 (mfranz) /var/cvs/FlightGear-0.9/source/src/Main/fg_commands.cxx remove the terrain-elevation command again. This is no longer necessary, as we have the geodinfo() Nasal function now. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-03_12:28:32 (mfranz) /var/cvs/FlightGear-0.9/source/src/GUI/dialog.cxx John DENKER: validate_format(): handle multiple flags correctly =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-03_13:07:51 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/wxradar.cxx /var/cvs/FlightGear-0.9/source/src/Instrumentation/wxradar.hxx make target RTT texture configurable as radar-texture-path =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-04_12:41:24 (durk) /var/cvs/FlightGear-0.9/source/src/Airports/dynamicloader.cxx /var/cvs/FlightGear-0.9/source/src/Airports/runwayprefloader.cxx /var/cvs/FlightGear-0.9/source/src/Airports/xmlloader.cxx /var/cvs/FlightGear-0.9/source/src/Airports/xmlloader.hxx Thomas Foerster: I refactored the XML loading code out of FGAirportDynamics and FGRunwayPreference. I also added a new class XMLLoader, which serves as a facade to the loader functions. Further I changed FGRunwayPreference to just keep a FGAirport ref, which is more concise and closer to the right(tm) solution than storing the airport data a second time ;-) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-04_12:42:20 (durk) /var/cvs/FlightGear-0.9/source/src/Airports/dynamicloader.hxx /var/cvs/FlightGear-0.9/source/src/Airports/runwayprefloader.hxx Thomas Foerster: I refactored the XML loading code out of FGAirportDynamics and FGRunwayPreference. I also added a new class XMLLoader, which serves as a facade to the loader functions. Further I changed FGRunwayPreference to just keep a FGAirport ref, which is more concise and closer to the right(tm) solution than storing the airport data a second time ;-) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-05_10:27:10 (mfranz) /var/cvs/FlightGear-0.9/source/src/Instrumentation/tacan.cxx Vivian MEAZZA: remove no longer needed debug messages =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-05_14:00:59 (durk) /var/cvs/FlightGear-0.9/source/src/Airports/dynamicloader.cxx /var/cvs/FlightGear-0.9/source/src/Airports/dynamicloader.hxx /var/cvs/FlightGear-0.9/source/src/Airports/gnnode.hxx /var/cvs/FlightGear-0.9/source/src/Airports/runwayprefloader.cxx Thomas Foerster: Made FGParking a subclass of FGTaxiNode Fixed bug due to longstanding inconsistency in FGAirport getter functions return types. Durk Talsma: Fixed traffic record initialization bug that occured when taxiing traffic was waiting for traffic on runway =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-05_14:01:00 (durk) /var/cvs/FlightGear-0.9/source/src/Airports/runwayprefloader.hxx Thomas Foerster: Made FGParking a subclass of FGTaxiNode Fixed bug due to longstanding inconsistency in FGAirport getter functions return types. Durk Talsma: Fixed traffic record initialization bug that occured when taxiing traffic was waiting for traffic on runway =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-05_16:27:17 (andy) /var/cvs/FlightGear-0.9/source/src/GUI/layout.cxx sync with trunk 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
[Flightgear-devel] Weekly CVS Changelog Summary: FlightGear data
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-01_10:05:16 (mfranz) /var/cvs/FlightGear-0.9/data/Nasal/io.nas implement writexml() function for writing non-standard XML files (that is: such that don't use PropertyList as root element and have data hidden in attributes) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-01_13:14:57 (martin) /var/cvs/FlightGear-0.9/data/Aircraft/c182rg/Models/chrome2.rgb Stuart Buchanan: Additionally, the texture chrome2.rgb is missing from the c182rg/Models/ directory. Can a committer please copy c182/Models/chrome2.rgb over please? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-01_13:54:32 (mfranz) /var/cvs/FlightGear-0.9/data/Nasal/io.nas what I do best: cosmetics =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-02_00:53:19 (sydadams) /var/cvs/FlightGear-0.9/data/Aircraft/Citation-Bravo/Models/breakers.rgb /var/cvs/FlightGear-0.9/data/Aircraft/Citation-Bravo/Nasal/Electrical.nas Updating the Bravo to where it was before I reinstalled my OS ... not nearly done yet =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-02_15:58:30 (mfranz) /var/cvs/FlightGear-0.9/data/Nasal/debug.nas output ghosts in a readable form =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-02_16:09:28 (mfranz) /var/cvs/FlightGear-0.9/data/Models/Airport/supacat_winch.ac /var/cvs/FlightGear-0.9/data/Models/Airport/supacat_winch.xml AJ MacLEOD: spin the drums =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-03_02:12:13 (sydadams) /var/cvs/FlightGear-0.9/data/Aircraft/Citation-Bravo/Models/breakers.rgb more model / texture updates =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-03_17:56:28 (martin) /var/cvs/FlightGear-0.9/data/Aircraft/787/Models/Attic/contrail.ac Joshua Wilson: 787/787.xml modified to more accurately reflect the characteristics of the 787. Slight modifications made to 787-set.xml, 787.ac (including engines, pylons, and stablizers), Models/787.xml, hud.ac, and hud.xml. 777 removed from system.nas. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-03_18:00:39 (martin) /var/cvs/FlightGear-0.9/data/Aircraft/787/Panels/dash-panel.xml /var/cvs/FlightGear-0.9/data/Aircraft/787/Panels/radio-panel.xml Remove DOS line endings. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-04_10:26:25 (mfranz) /var/cvs/FlightGear-0.9/data/Aircraft/Lightning/Models/radar.rgb /var/cvs/FlightGear-0.9/data/Aircraft/Lightning/Models/sector.rgb AJ MacLEOD: initial effort to convert radar to 3d =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-05_02:42:57 (dfaber) /var/cvs/FlightGear-0.9/data/Aircraft/bf109/Models/cooltemp.xml coolant temperature gauge now working. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-05_07:52:17 (dfaber) /var/cvs/FlightGear-0.9/data/Aircraft/F4U/Models/transparent.ac /var/cvs/FlightGear-0.9/data/Aircraft/F4U/Models/transparent.xml model display improvements for plib =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-06_00:38:50 (sydadams) /var/cvs/FlightGear-0.9/data/Aircraft/Citation-Bravo/Nasal/Electrical.nas Added a few more functioning annunciators... master caution and master warning hotspots for RESET... Added inverter to the electrical system (AC power) Tweaked FDM a bit , too much solve weight with full fuel ... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-07-07_14:51:33 (sydadams) /var/cvs/FlightGear-0.9/data/Aircraft/Citation-Bravo/Nasal/Electrical.nas Updated FDM... Added flight-hour-meter property (with tenths of a minute) to instrumentation/clock Fixed broken AOA needle ammeter gauges animated ... 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
