Re: [Flightgear-devel] static friction patch
On 04/14/2013 06:13 PM, Diogo Kastrup wrote: > A long time ago I started working on a different implementation for > YASim static friction. With help from Csaba and Mathias Fröhlich the > patch worked but I never finished polishing it to submit a final > version. Vivian poked me about this one, so I got here in time for a change. :) Can I be a jerk and kick this back for patch formatting reasons? I think I get the idea here: it's detecting the "stopped" condition and replacing the existing friction mechanism with a spring model around a fixed point. And that makes sense to me. But it's really hard to review: there's no commit message explaining what's happening; lots and lots of the modifications are just whitespace changes to existing code that I have to prune out to read the real changes; some things just don't make sense, like the apparent addition of tmul33() and family to Math.hpp which I swear was there before... Would it be too much to ask for Diogo (or anyone else) to do a cleanup pass on this? Andy -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim and documentation
On 10/05/2012 05:53 AM, Vivian Meazza wrote: > Andy is still around, but inactive. It might be possible to run stuff by him > once in a while. He even reads the mailing list (but not the forums) on occasion. :) Indeed, I'm busy with other things these days, but am still broadly happy to answer questions if posed (as long as I remember enough to come up with a meaningful answer). Just cc: me if you do, because my latencies here are measured in weeks. > But I would in general worry about mucking about with such a > critical part of FG, unless I was very sure about what I was doing. Bugs can always be fixed. What YASim needs is a maintainer, not really expertise per se. The latter comes from the former. Andy -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Yasim static friction?
On 07/05/2012 02:41 PM, Viktor Radnai wrote: > Thanks for that! So just to clarify -- this is a bug in Yasim code (or > more like a missing feature) and I'm welcome to fix it?:) I'm just an absentee hacker, so I can't say what is or isn't acceptable any more. But it seems like a sane enhancement to me. But broadly yes: it's free software. The whole point is to make it do what you want. Andy -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Yasim static friction?
(Happened to be browsing in time to see a question) On 07/05/2012 06:21 AM, Viktor Radnai wrote: > I don't see any obvious properties to set to take the engine's > resistance to turning over, or the friction of the wheels into account > to stop these unrealistic things from happening. How should I go about > fixing them? That sounds right to me. Aircraft parked in gentle winds weren't really part of the original test regime. :) For the gear thing, see Gear.cpp:450 or so, and look at clamping the static friction coefficient to some minimum value (probably tunable). For the engine, you can likewise add some fixed negative torque value near PistonEngine.cpp:214 to model internal resistance (currently the code only models output power). Andy -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
On 05/23/2012 12:04 AM, Erik Hofman wrote: > Hi Andy, how's life? > I did already search for a new release of Nasal on your site but I > believe flightgear already uses the latest version. The most recent code (except for a few modules that were never imported) is in SimGear. I threw my copy up on github a while back if there is any question about variants: https://github.com/andyross/nasal Andy -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
On 05/20/2012 11:37 AM, Stefan Seifert wrote: > Generational garbage collection is not that difficult. When you have a working > mark& sweep GC, extending it to be generational is rather straight forward > and can greatly reduce GC runtime Runtime, yes, but not latency bounds. You still have to touch the whole heap eventually. But you're right: allocating objects into generations and only mark/reaping from the most recent one on most iterations is a straightforward optimization and will definitely make things faster. Andy -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
On 05/20/2012 10:17 AM, James Turner wrote: > This is interesting - as far as I know, the current GC does not > include a maximum delay and restart facility. If it did, that would > entirely satisfy the current issues. At least by my understanding. > > Equally, I've looked at the current GC code and didn't notice any > code to support this feature. Does anyone else have any further > information about this? Since it would be far simpler and more > robust than any other solution thus suggested. I was lucky enough to notice this come by. I wouldn't hold your breath. :) This was an experiment, and honestly I have no idea why I put it in the docs. The idea was to do the GC normally, check timestamps periodically, and then longtmp() out of it past some threshold, leaving the intermediate sweep stuff in place. But that's not enough, because now you need to track all mutated reference-storing objects in a separate list so they can be swept again. And you need to have some kind of heuristic for when it's OK to restart the sweep. I have a vague memory of being sure I'd cleverly solved this, but I never got it working and at this point, frankly, I suspect I was wrong. In my advancing age, I've come to believe that low-latency GC is just a pipe dream. You can have a realtime GC or you can have a production system, but you can't have both at the same time. Every managed runtime in the modern world has latency bugs in some application or another, every one of them. Andy -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Efficient Nasal coding (was: Stuttering at 1 Hz rate)
On 03/29/2011 11:31 PM, thorsten.i.r...@jyu.fi wrote:
> for (var i =0; i< 30; i=i+1) # number of objects is 30
>
> is superior to
>
> var number_of_objects = 30;
> for (var i = 0; i < number_of_objects; i = i+1)
No it isn't. Variable references aren't garbage (well, they aren't
heap blocks, though they do get traced). The things they point to are
garbage, and a number isn't a reference in Nasal. The "30" in the
second example gets stored (as a double) directly in the hash record
in place of the pointer that would be there if it were a reference.
The "var" syntax has no meaning as far as allocation. It's about scoping,
it says "make this a local variable in the current function no matter what
outer scope it might also be in".
The operations in Nasal that create heap blocks/garbage are:
1. String composition with the "." operator
2. Vector creation with a "[...]" expression
3. Hash creation with a "{...}" expression
4. Function calls (which create a hash for the namespace)
5. Closure binding with a "func ..." expression.
I believe that's all of it, though I may have forgotten something.
Andy
--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default Aircraft Candidates
On 02/22/2011 04:09 PM, Ryan M wrote: > I am not a 777 pilot in real life, but I certainly agree with Jack that > the FDM seems unrealistic to the casual pilot. For those interested (Curt made me look at a YASim file last week for the first time in over a year, so my head happened to be in the right place), I took a peek at why this would be: The 777-200 configuration I see in HEAD on gitorious has an approach setting that says it can stay in the air with 7 degrees of AoA (about half of the available lift) at 120 kts with 80% of its fuel and a full load. That strikes me as more than a little optimistic. This is a long haul jet, its fuel is a big fraction of its maximum weight, and typical landings for jet like this are made at what, 15% fuel or less? (It can stay in the air for 11 hours, and you only need 45 minutes of reserve fuel, right?) So some quick math says that if you take this aircraft which can produce 1G at 120kias and reduce its mass by a factor of 1.74x by dropping the passengers and using 10% fuel, and pull it up to a stall AoA, you'll get 3G of acceleration. Speed up to just 207 kias, and you can pull 9G in this plane. Yeah, that's a fighter jet. I'd suggest 131 kts (which matches the landing speed in the coments) and 10% fuel and see how that works. Andy -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sinking feeling - c172 on gravel runway
On 02/11/2011 11:54 AM, Alasdair wrote: > You will note in all further dicussions that I will refer to "nasal" > as NASAL (Not Another Scripting Language), which denies its very > existentence through a lie in its own nomenclature. cf "GNU" which > makes no such assertion, but was probably dreamed up by a brainy > recursionist like Csaba. Yeah. That guy was a serious egghead. What happened to him? Andy -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] urgent git help requested
On 02/09/2011 12:02 AM, Tim Moore wrote: > "Backing out" is done with git reset --hard last_good_commit. Often the name > of the last good commit is HEAD^, the last commit. However, after a botched > merge it is good to verify that with git log or graphically with gitk. Actually, unless I've misunderstood your point, this won't work: the commit history following a merge is an interleaved mix of two branches. You can't just walk back to "before" the merge. Doing that gets to to the equivalent of git merge-base, which is the last version that includes *none* of the changes in *either* branch. I don't think that's what Curt wants. See my comment to Anders about git reflog. (and yes, I've made exactly this mistake in the past, heh) Andy -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] urgent git help requested
On 02/08/2011 11:04 AM, Anders Gidenstam wrote: > Backing it out might be a bit tricky, but you can rename your messed up > branch out of the way easily with git branch -m oldname newname. It's worth experimenting with "git reflog" in situations like this. That tracks a list of HEAD references in strict chronological order (i.e. what has HEAD been in the past, not what commits were done). In cases where you've completely mucked up the revision history, you can look at this to see what you were doing before, recover the commit ID, and do a reset --hard to that. Andy -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
[saw this in time to de-lurk] On 01/25/2011 11:22 AM, Anders Gidenstam wrote: > I suspect the option --local to git clone might be useful. > I have not tried myself, though. Yeah, this is the best answer for this kind of problem. The .git directory ends up being near-zero size (so long as the deltas between trees are small), and you pay only for the copy of the active tree. So resource consumption is more or less the same as having two "checkouts" of a remote tree. You do have to manage the extra steps required to push/pull/merge between the trees though. Andy -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FPE in yasim::Atmosphere::calcStdDensity
On 12/08/2010 02:14 PM, Roland Haeder wrote: > And the temperature at EDDL can now really be at 0 deg. Celsius because > of winter time. :) Just happened to see this come by. That function takes temperatures in kelvin. And the pressure (absolute also) was likewise passed in as zero. This is an initialization bug, those aren't numbers the physics can deal with. Andy -- This SF Dev2Dev email is sponsored by: WikiLeaks The End of the Free Internet http://p.sf.net/sfu/therealnews-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] dumb git question
Thought I'd chime in here, as I've been going through the git
transition pains myself recently, and the other answers have been all
about the "what" and not the "why" of the task.
Git adds an extra level of indirection that you're not used to: the
cvs/svn model of the world had only one repository. So when you
wanted to "forget" a modified file you would just remove it and issue
the command ("update") that copies changes from the repository to your
working directory. The act of "forgetting" a change was identical
with fetching new changes from upstream, so you used the same command.
With git, those are two different tasks! The command to pull changes
(not current data, just changes against what you already have) from
another repository is "pull"*. If it happens that someone else has
pushed a change to the file you want restored, this will actually do
what you want, but only by accident.
The command to copy stored versions in your local (!) repository,
which is what you want to do, is (unfortunately, IMHO**) named
"checkout". This will by default copy from whatever the head your
current branch is, and you can specify file or directory names.
Andy
* Which is really the combination of two lower-level commands: "fetch"
simply copies in the branch data but doesn't touch your current
working area, and "merge" which merges changes from another branch
into your working tree.
** It's only "checking out" of a local repo you control. Originally
the term was a metaphor for library borrowing: you checked out a
SCCS/RCS file the same way you did a book, and gave it back when
you were done. The git usage implies that it's touching shared
data somewhere, when it's not.
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim "effectiveness" tag
On 05/26/2010 12:44 AM, James Turner wrote: > This is a wild guess, but from memory (of discussions here), and reinforced > by the code snippet above, effectiveness is a hack/tweak to account for > surfaces/controls that work better/worse than YASim predicts. So > effectiveness of 1.1 makes the flaps 10% more effective. I would assume it's > a tweak so you can say, well, the model is basically okay, but it doesn't > respond to xyz quite right. Heh, I actually noticed my name on the list in time to respond this time! Yes, this is exactly right. The effectiveness is just a scalar multiple on all force produced by the component which is otherwise (mostly) linear with surface area. It's a useful lever for tuning, but if you find you need to go beyond a factor of two (i.e. 0.5 - 2.0) I'd look elsewhere for the problem. Andy -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal alternatives : possible, of course,
Oh, man -- giant Nasal flame war and I totally missed it. Melchior just now pointed me here. Sadly (or, well, not at all, actually) Andy's been doing a lot more of the daddy thing than the hacker thing recently. Some quick shots after the fact: Nicolas Quijano wrote: > It's also brilliant, smaller (runs on cellphones) and faster than > nasal (that's an opinion, but I really can't see how anyone says > Nasal is fast, at least from my experience so far) While Lua is pleasingly small, it's certainly not smaller than Nasal, either in code size or size of runtime data (especially at runtime: Lua lacks anything like the vector type Nasal has and can't represent packed arrays). And I also had Nasal running on various phones* back in 2004/5 when I was doing that stuff for my day job. [* Not, by the way, that phones are particularly "small" any more. Sure they can run Lua and Nasal: also Javascript, one or more JVMs, a .NET CLR interpreter, often a flash interpreter, bash, perl, python, VB, ...] As far as speed goes, the last time I was doing any benchmarking Nasal was about as fast as Perl 5 or Python 2.2 at most things. It's garbage collector was faster, its symbol lookup about the same or slightly faster, and its bytecode interpreter somewhat slower. I'm not aware of any FlightGear usage where Nasal's performance is an issue, but I'm willing to take bug reports. And I'm amused that you feel free to express an "opinion" about a quantitative subject. Either Nasal is or is not faster or smaller than Lua; I'm not sure what your opinion is coming from if not measurements. :) > And I won't mention that is has no adequate documentation and no > debugger. Period. (<-- that's very serious) If you say so. I've been writing script code in perl and python for a decade and a half and haven't ever felt the need to use a debugger in either environment. That's very much a taste thing. If you can't handle the need to call print() or write an if() to inspect or trigger on runtime state and want to type into a command window instead, that's cool. Just don't pretend that everyone feels the same way. The documentation thing sounds more like a cheap shot than a real complaint -- is there something you'd like to see documented that isn't? We don't have books on Nasal. We certainly do have docs. So as far as flames go, some stuff off the top of my head that was, I think, true at some point in the past. I'm not 100% confident on all this, because my Lua knowledge is pretty stale. + Nasal is threadsafe. Lua has a global interpreter lock. + Nasal is stackless for interpreted code. Lua recurses on the CPU stack. + Nasal is a true functional language, with lexical scoping, runtime binding and true closures. Lua has a clunky global namespace. + Nasal has complete programmatic control over the runtime namespace for any piece of code, making "modules" a question of script coding and allowing a bunch of neat metaprogramming tricks along the lines of what the Ruby folks do with their monkey patching. Take a look at the (non-FlightGear) Gtk library for some examples. Lua, again, has a clunky global namespace. + Nasal's data model matches what you are used to from perl, python and javascript. Lua's is ... odd. + Nasal has a true garbage collector. Lua has a reference counter that can't handle circular references. + Nasal has syntax that makes sense in the modern world and to programmers exposed to other languages like Javascript. Lua looks like PL/1. But hell, there's really nothing (other than cosmetics) wrong with Lua. As you mention, it's grown into a large community with lots of documentation and libraries and professional-looking trappings. None of that was true in 2003/4 when Nasal was in its infancy, but it is now, and I can see why it would be attractive. If you want to do the integration work and maintain it (remember, there's a ton of code outside the interpreter you need to write to be able to do useful things inside the simulator), feel free. > Why was Nasal chosen in the first place ? Wasn't it to supplement a > fledgling FDM module at the time, yasim, that was lagging behind > jsbsim and its property system ? Or so I've inferred and been told Ooh, a YASim flame too. Bring it on. :) Andy -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory corruption in Nasal with MSVC
Frederic Bouvier wrote:
> I get memory corruption caused by writing outside an malloc'ated memory
> bloc. I tracked the problem down to the recsize() function ( in hash.c )
> computing a memory size that is not enough for subsequent initialization
> in resize()
Wow, good catch. This was also reported on the nasal list as a difference
between optimized and non-optimized builds on 32 bit linux. I tracked it
down as far as recsize() returning the wrong value, but then wrote it off
as a compiler bug and didn't investigate further. I missed the alignment
issue completely.
Try the following patch, which will force the alignment but still allow the
use of the (IMHO) clever trick to get the memory block size in a single line:
Index: hash.c
===
RCS file: /home/nasal-cvs/nasal/src/hash.c,v
retrieving revision 1.51
diff -u -r1.51 hash.c
--- hash.c 26 Sep 2008 17:53:29 - 1.51
+++ hash.c 25 Nov 2008 17:18:02 -
@@ -96,9 +96,12 @@
static int recsize(int lgsz)
{
-HashRec hr;
-hr.lgsz = lgsz;
-return (int)((char*)&TAB(&hr)[POW2(lgsz+1)] - (char*)&hr);
+/* Union with the pointer for alignment purposes, to guarantee
+ * that the dummy HashRec has the same alignment as the malloc
+ * block that will eventually contain the real one. */
+union { void* align; HashRec hr; } u;
+u.hr.lgsz = lgsz;
+return (int)((char*)&TAB(&u.hr)[POW2(lgsz+1)]) - (char*)&u.hr);
}
static HashRec* resize(struct naHash* hash)
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] New nasal drop, new syntax
Note that a reasonably big Nasal change just went into SimGear.
Melchior had a chance to test it out first, so hopefully not too much
will have broken. The documentation for the new syntax is below.
There's also been some work done to reduce the memory footprint for
strings (store short strings inside the structure), hashes (about a
60% overhead reduction) and function closure objects (about 100 bytes
each).
As always, let me know what broke.
New syntax:
1. Call-by-name function arguments. You can specify a hash literal in
place of ordered function arguments, and it will become the local
variable namespace for the called function, making functions with many
arguments more readable. Ex:
view_manager.lookat(heading:180, pitch:20, roll:0, x:X0, y:Y0, z:Z0,
time:now, fov:55);
Declared arguments are checked and defaulted as would be expected:
it's an error if you fail to pass a value for an undefaulted argument,
missing default arguments get assigned, and any rest parameter
(e.g. "func(a,b=2,rest...){}") will be assigned with an empty vector.
2. Vector slicing. Vectors (lists) can now be created from others
using an ordered list of indexes and ranges. For example:
var v1 = ["a","b","c","d","e"]
var v2 = v1[3,2]; # == ["d","c"];
var v3 = v1[1:3]; # i.e. range from 1 to 3: ["b","c","d"];
var v4 = v1[1:];# no value means "to the end": ["b","c","d","e"]
var i = 2;
var v5 = v1[i]; # runtime expressions are fine: ["c"]
var v6 = v1[-2,-1]; # negative indexes are relative to end: ["d","e"]
The range values can be computed at runtime (e.g. i=1; v5=v1[i:]).
Negative indices work the same way the do with the vector functions
(-1 is the last element, -2 is 2nd to last, etc...).
3. Multi-assignment expressions. You can assign more than one
variable (or lvalue) at a time by putting them in a parenthesized
list:
(var a, var b) = (1, 2);
var (a, b) = (1, 2); # Shorthand for (var a, var b)
(var a, v[0], obj.field) = (1,2,3) # Any assignable lvalue works
var color = [1, 1, 0.5];
var (r, g, b) = color; # works with runtime vectors too
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [SECURITY] Nasal: io.open() restricted
Sven Almgren wrote: > But is this really needed? How does M$ flightsim extensions do? You > have to trust the source somewhat, We could sneak in bad code in > fgfs too, and ppl would run it anyway... Can the addoncreators be > trustet as much as "we" can? Sure. FlightGear is a local program, and software it loads from the local drive can certainly do local I/O if it wants without breaking typical security models. That's the whole idea behind being able to download software from the internet in the first place. :) My historical fear has been the interaction with the MP environment: the MP code can write to the property tree, and arbitrary property nodes have on various occasions be hooked to execute Nasal code. Being able to execute arbitrary Nasal code on another machine over the network would be a security disaster if that code could do I/O or spawn programs, etc... What Melchior has done is fine with me, architecturally. Ideally, I guess I'd prefer a sandbox on the other side: an architecture that expressly prevents network data from being executed somehow, probably by strictly limiting the areas in the property tree it can write to. But this kind of architecture can work too: it just requires that every "potentially unsafe" operation be sandboxed in the same way as I/O. Andy - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flying on the EDGE
Torsten Dreyer wrote: > While the YASim engines don't warm up the burned air at all (egt > equals ambient air temperature) That's almost certainly because something is wrong in the engine configuration, probably displacement or compression ratio (which wouldn't otherwise cause problems if they were wrong). The clamping to ambient is done as a safety valve only. The relevant code is in PistonEngine.cpp:244 if you want to take a look. Andy - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] valgrind diff no 2 and 3
till busch wrote: > * f_interpolate in NasalSys was leaky (valgrind) This leak is real, but the patch isn't legal C++, at least as of the last time I read the standard. You can't initialize a stack array with a dynamic value, it has to be known at compile time. This is a gcc extension. Better just to delete the arrays. Fixed in CVS. > --- src/Scripting/NasalSys.cxx5 Dec 2007 10:57:51 - 1.97 > +++ src/Scripting/NasalSys.cxx21 Jan 2008 21:30:11 - > @@ -317,8 +317,8 @@ static naRef f_interpolate(naContext c, > naRef curve = argc > 1 ? args[1] : naNil(); > if(!naIsVector(curve)) return naNil(); > int nPoints = naVec_size(curve) / 2; > -double* values = new double[nPoints]; > -double* deltas = new double[nPoints]; > +double values[nPoints]; > +double deltas[nPoints]; > for(int i=0; i values[i] = naNumValue(naVec_get(curve, 2*i)).num; > deltas[i] = naNumValue(naVec_get(curve, 2*i+1)).num; - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug#461399: simgear_1.0.0-1 (alpha/unstable): FTBFS: Unrecognized CPU architecture
Ove Kaaven wrote: > It's not just him being cranky about his own pet issues, it's > about policy and the pursuit of high software standards. High "standards" for software you (literally!) can't run? Please. This is pedantry and egotism at its worst. I'm terribly sorry my software isn't good enough for you, I really am. But you can either work with me to fix it or take potshots about trivial build problems and "Heisenberg bugs" that can't actually be exhibited. You and Steve picked the latter. > I think he already provided the requisite defines, though > somewhat buried in his mail. Beyond that, perhaps this web page > would be of interest: > http://predef.sourceforge.net/prearch.html No, someone needs to *run* this and *test* it on those architectures.* I'm not going to commit blind changes to either Nasal or SimGear. Since you can't actually run the code you are complaining about, someone needs to work with the command line Nasal interpreter from http://plausible.org/nasal to do the test. [* Something, I will point out yet again, that no one has done. Do either you or Steve have console access to a s390, Alpha, or PA-RISC box with 3D hardware? Has *anyone* ever run the Debian fgfs binary on those architectures?] And I'd very much prefer the gcc output I asked for to anything that comes out of a single individual's brain. This stuff is too easy to get wrong, and it's literally one command to run. Just run it and send me the output. Or don't, I guess. Your call. Andy - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug#461399: simgear_1.0.0-1 (alpha/unstable): FTBFS: Unrecognized CPU architecture
Ove Kaaven wrote: > It looks like there are some portability issues in the current > code... On three platforms which don't have the CPU power (or GPU support!) to actually, y'know, run the software. :) > Steve Langasek wrote: > > So this assumes the kernel will never expose more than 48bits of > > address space to userspace processes -- a short-sighted and > > groundless assumption, the reason Linux hasn't "documented this > > rigorously" is because there is no such guarantee. The NASAL_NAN64 > > option should be thrown out for all Linux variants. This is in the Nasal interpreter. Language interpreters routinely enjoy making some platform assumptions in the name of performance. In this case, that union trick chops the size of a naRef (and therefore the memory footprint of almost everything Nasal does) in half. I'm more than prepared to pay for this benefit in the form of the occasional dispeptic rant from uninformed distribution folks who are more interested in wagging their fingers at developers than they are in actually running the software [How's that for tone, Steve? I can flame with the best of them if you really want to throw down. Try a little less presumption next time.] As explained very clearly in the comments, all known platforms support this code just fine, and the benefits are very large. And I'm even conservative about refusing to compile on platforms on which I can't test, thus the #error (it's a feature, not a bug!). I'm happy to take patches, though. This support is trivially really easy to add, if Mr. Langasek is actually willing to help out a little. Just the output of "echo | gcc -dM -E -" on each of the platforms is sufficient. > > ... which is a cop-out, and a serious regression because the old code built > > and ran fine on all architectures. On all *debian* architectures. I had a ton of trouble getting the original stuff to work for everyone who wanted to use it. Manually enumerating architectures was the overwhelmingly simpler choice. I'm sorry you disagree. Andy - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] BUG: FG HEAD fails to compile after recent changes to configure.ac (reverting fixes it)
Curtis Olson wrote: > I just committed a patch that should fix this configure.ac problem. > Guys, it looks like no one tested this patch before committing it It worked for me. Probably because my LD_LIBRARY_PATH is set such that the resulting configure-generated programs can run? The genesis of the commit was a complaint on the IRC channel by Hans that the OS X build had been broken for a long time, and that patches to fix that (the whole point here was to use the Apple-specific AC_CHECK_FRAMEWORK macro for the OSG libraries on OS X) had been ignored for weeks. I read it, nodded, tried it and committed. IMHO, it's better to have a little grief on the development list than leave an important user platform broken like that. Andy - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear prerelease; RPMs available + PATCH
> So it's only missing #include which should > be in the code. See the attachments. > > [...] > > #include > +#include > +#include Surely that should be , no? It's just a style thing, but if you're modifying code that is already using ANSI C headers, and not Standard C++ headers, you should stay with the existing convention. It's especially weird to add one of each. :) Andy - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Stutter/Nasal issue resolved (was: FlightGear/Plib periodic stutter notes)
Csaba Halász wrote: > Don't know if Melchior and Andy have arrived at anything while I was > away, but here is what I found. Yup, that's exactly it. New nasal objects are added to a temporary bin when they are created, because further allocation might cause a garbage collection to happen before the code that created the object can store a reference to it where the garbage collector can find it. For performance and simplicity, this list is stored per-context. When the context next executes code, it clears this list. Here's the problem: we do a lot of our naNewXX() calls in FlightGear using the old "global context" object that is created at startup. But this context is no longer used to execute scripts* at runtime, so as Csaba discovered, it's temporaries are never flushed. That essentially causes a resource leak: those allocations (mostly listener nodes) will never be freed. And all the extra "reachable" Nasal data floating around causes the garbage collector to take longer and longer to do a full collection as time goes on, causing "stutter". And scripts that use listeners extensively (the cmdarg() they use was one of the affected allocations) will see the problem more seriously. * That's a feature, not a bug. Once listeners were added, scripts could be recursive: (script A sets property X which causes listener L to fire and cause script B to run) We need two or more contexts on the stack to handle that; a single global one won't work. I didn't like the fix though. Exposing the temporary bin as part of the Nasal public API is ugly; it's an internal design feature, not something users should tune. Instead, I just hacked at the FlightGear code to reinitialize this context every frame, thus cleaning it up. A "proper" fix would be to remove the global context entirely, but that would touch a bunch of code. Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The Release
olaf flebbe wrote: > > If my memory serves, VC8 shipped with a new runtime that won't work > > on XP without an update, right? > > Wrong. Can you elaborate? I'm all but certain that default builds want to link against MSVCR80.DLL (or whatever) at runtime, no? Are we set up to install that in our distributables? Is such an arrangement GPL compatible? I know other projects have had to deal with this issue, but don't know the details. It does strike me as simpler to just use the older compiler. Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The Release
olaf flebbe wrote: > Please do not mix the terms "compiles o.k. and works for me" with > "the code is correct". I did no such thing. The issue here is whether or not the code is the *same* as the one we are shipping on other platforms. Yours is not, and therefore really shouldn't be packaged up into a release. But you're absolutely right: this looks like a plib bug to me too. You should re-submit that fix to the plib folks, not us. (And not as a MSVC8 "build patch" -- I wasn't looking for bugs in it, for example, and missed this one entirely). We can't fix plib bugs here, and if this isn't a showstopper for the release (it's not) posting it to a thread titled "The Release" and demanding that it be applied is probably going to confuse things more than help. And I still think that flightgear-devel is an inappropriate forum for discussion plib problems. Our goal here should be to get it building for the release, only. Note that all of this code has *already* been obsoleted in the CVS trunk anyway. After this release, it simply isn't possible for us to hit this bug, or any other problem with ssg, ever again. Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The Release
olaf flebbe wrote: > As a side note: The gcc does not enforce const-correctness very > much. Sigh, and the flames continue... Your basis for that statement is what, exactly? Of course gcc enforces const correctness. I suspect what's happening here is that plib, which is using and not , is getting the C implementation declared. I'm not sure where the C++ standard requires here. Arbitrary libc headers obviously need to pass through compatibly, but maybe there are special requirements for the ANSI headers. > Unfortunatly they still miss MSVC8. Is the problem simply that VC8 has trouble? Isn't the obvious solution then to build with VC7 instead? If my memory serves, VC8 shipped with a new runtime that won't work on XP without an update, right? We probably want to build with the compatible compiler anyway. Regardless, you need to fix that patch if you want to see it used. Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] formatting in nasal
Syd&Sandy wrote: > No its not a typo , I want a single string property to hold > groundspeed ,TTG and ET , depending on which mode is selected for > display on the Primus PFD OK. You might want to make that property a string, though, or at least an integer. Storing a fracional number there and extracting things via math is going to cause precision glitches. As it happens, your example is affected by this: 2.3 is not exactly representable as an IEEE double. So you can get different results depending on code path. My example of multiplying it 100 actually doesn't work, because 100*2.3 comes out as 229.9. But if you really do have more than one value, don't be afraid of putting them into separate property nodes. They're cheap. Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The Release
Hans Fugal wrote: > I could be wrong, but I think you missed his point. I don't think he > was arguing that you couldn't cast a const char* to a char*. The > argument was that without the cast it doesn't work, and the cast is > bad form and leads to bugs. A point, you will note, I never disagreed with. Nonetheless we use plib. And plib's code has "bad form" and even the occasional bug. Since we use it, we need to build it. It was remarked at the top of this thread that plib 1.8.4 required a patch to build. I noted first that the patch seemed unnecessary (and only later noticed it was wrong), and suggested that the problem (in plib's code, not ours) could be fixed via adjustment of the warning level of the compiler instead. At which point all you guys in the peanut gallery jumped on me about "bad form" and I started swinging back. > I think it's a reasonable argument, not one that needs derision. It is not a reasonable argument in this context, as it involves source code we don't control. And I'd argue the derision started in John's message, for what it's worth, but I suppose that's an issue of taste. The goal here, I will point out yet again, isn't to decide how best to develop plib, but to decide how best to get it built under windows for a FlightGear release. I'd argue that building our released version against an inconsistent library dependency constitutes significantly *worse* form than tolerating some const-incorrectness that has already been vetted out on other platforms. Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] formatting in nasal
Syd&Sandy wrote:
> Hi all , is there a way to format a double and output that to a
> string property with writing the double to a property first . Should
> be doable but it escapes me at the moment ...
>
> Example : (double) 2.30 to (string) 2:30
Nasal numbers will convert directly to strings according to fairly
standard representations. Just use them directly, no conversion is
neccessary:
var val = 2.3;
var msg = "The value of 'val' is: " ~ val;
If you need fancy formatting, like for example limiting the output
precision, there is a sprintf() function available that works just
like the ANSI one:
var msg = sprintf("The value of 'val' is: %.2f", val);
I'm not sure if the colon in "2:30" is a typo or not, but that's
possible too with a bit of work:
var frac = math.mod(val, 1);
sprintf("Formatted: %d:%2.2d", val-frac, 100*frac);
Andy
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The Release
Csaba Halász wrote: > Note that literal string constants may be allocated in read-only > data section, thus causing segmentation fault at runtime. Try > calling your "foo" function passing a literal string, What does this have to do with the discussion? We are talking about const pointers, not linker segments. And in any case I already mentioned (and dismissed) this possibility. From three posts above: I wrote: > Are you maybe trying to say that plib is writing to a static string > constant? That would be a pretty serious bug if true, but as far as > I can see it's not. This flame war might be a whole lot more productive if people would stop trying to show off about their C knowledge and trying harder to figure out what the appropriate way to get plib to build under MSVC is... Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The Release
I wrote:
> Plib's behavior in the lines touched by this patch is platform
> independent.
And this bit of the patch is just flat wrong. The original version
finds the first "_" in the string and nul-terminates it at that
location. The "fixed" code it a complete no-op.
- char *p = strrchr(fname,'_');
+ char *dupfname = strdup( fname);
+ char *p = strrchr( dupfname,'_');
if (p != 0) {
*p = '\0';
The confusion seems to be that Microsoft declared strchr() as taking
and returning a const pointer. Which is broken, because strchr()
returns a pointer into the *same* memory it got. The constness needs
to be synchronized between the pointers, which is outside the
capabilities of the C language. So programmers have to choose between
a slightly "unsafe" function that drops const and one that requires a
cast to use with a non-const string.
Instead of adding the cast, you have copied the *whole* string to a
new buffer, terminated that one instead of the original string, and
then dropped it on the floor leaving the original string untouched.
Andy
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The Release
John Denker wrote:
> 2) It seems vacuous to compare writing via a const char* to
> writing via a non-const char*, because AFAIK there is no such
> thing as writing via a const char*. No compiler AFAIK will
> generate any CPU instructions for it.
Oh, good grief:
$ echo 'void foo(const char* p){*(char*)p=0;}' > tmp.c
$ gcc -S -c -o - tmp.c
Look! Instructions! I await your further pedantry about this
not "really" being a const pointer because of the cast, to which
I will reply that casts like this are precicely the subject of
discussion (hint: see olaf's patch)...
If it really concerns you, take it to plib-devel. It's not our
code. The question was whether the constness issues in the
released plib code are blocking bugs for a new FlightGear
release. As far as I can see, they are not. Plib's behavior in
the lines touched by this patch is platform independent.
Andy
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The Release
olaf flebbe wrote: > You may be wrong. They are writing to const char *. I had to strdup(). A "const" char* is exactly the same thing as a regular pointer at the level of CPU instructions. Writing to it does exactly the same thing as writing to a non-const pointer. The difference exists at *compile* time only. If MSVC is complaining about it, just adjust the warning level. Are you maybe trying to say that plib is writing to a static string constant? That would be a pretty serious bug if true, but as far as I can see it's not. Your use of strdup() is just adding an extra (and needless) step. Have you tried just adding a typecast instead? Again, the point here isn't whether or not plib's code is clean and will compile without warnings on MSVC. The point is whether it works the same as it does on our other platforms. Build issues are plib's problem, not ours. Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The Release
olaf flebbe wrote: > Durk Talsma wrote: > > SimGear require plib-1.8.4, but this version no longer builds on my > > box > > There is still an patch for MSVC8 waiting to be applied. Looking at that patch, it seems entirely typecast stuff. Those are warning conditions; I don't see any changes that would affect the generated code. Sure, it would be good to get plib to fix their typing conventions, but I can't see why it would stop it from building, and in for the purpose of our release the distinction is meaningless. Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Bug-Report] Stutterer and pauses withdynamic-view
Frederic Bouvier wrote: > I think stutter comes from the threaded scenery tile > loader. When you change view direction, you ask the loader to > load more tiles, and when all required tiles are loaded for a > given position, the stutter stops. That seems unlikely. The tile loader is very old code, and this is a new symptom. It's also, as you point out, threaded precicely for the purpose of *not* blocking the main rendering thread. Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal variables
Stewart Andreason wrote: > If accessing temp1 _is_ faster than .getValue, then at 2 or 3 > accesses, I imagine it becomes faster to do the above? Yes, it's definitely faster, because there's less work to do. Evaluating the expression "temp1" requires pushing the symbol value (a string) onto the stack, and executing OP_LOCAL which does a hash table lookup to find the value in the namespace list and leave it on the stack for the next bit of code to use. Evaluating "node.getValue()" requires: Pushing the symbol "node" onto the stack Executing OP_LOCAL to look it up Pushing the symbol "getValue" onto the stack Executing OP_MEMBER to look it up in the object Executing OP_CALL to call it as a function Finally (!) calling the C++ property node function Turn the output node into a Nasal object and leave it on the stack. That said, you really don't want to be designing your scripts around raw, low-level performance issues. Write your code to be readable, not blazingly fast. In general "altitude" is more readable than "altNode.getValue()". Andy - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal variables
Stewart Andreason wrote:
> Is there a preference for how variables are declared and used in nasal?
> between the global type:
> var some_name = 0;
> which can be accessed and changed from any function,
That's a Nasal variable. It's not "global" in the sense that all
users will see the same value for "name". It's part of the namespace
of the executing function (which might be the whole file), and is
visible only to the current function, and other "func" expressions
assigned during that execution.
> and using the nodes
>var name =
> props.globals.getNode("/sim/model/aircraftName/someDirectory/name",1);
> and accessing with .getValue and .setValue.
That's *also* a Nasal variable, but it holds a reference to a property
node instead of an actual value. Interestingly, the property node,
unlike the variable above, *is* a global thing (i.e. every part of
FlightGear sees the same node for /sim/model/.../name).
The advantage to Nasal-space data is that it's fast and simple. If
the only thing that will care about the value is your script, they are
good choices.
The property tree is a inter-subsystem communication thing. This is
what you want if you want to share data with the C++ world (for
example, YASim tags write to properties -- they don't
understand Nasal), or read in via configuration files.
Andy
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] spanning multiple columns in gui layout
John Denker wrote: > 4) I did not snipe. I did not sneer. I reported the facts as I > observed them. If observations conflict with your expectations, > what should I do? John, please. You asked for a new feature that already exists, and when corrected immediately reported that it doesn't work and isn't used, despite the fact that it does and is. You even hid behind (no joke) a grammar excuse (as if "colspan" and "rowspan" are so different that one couldn't possibly be an example of the other, or that you couldn't think to grep for just "span"). When told that the core of the "columns too small" problem was your use of an explicit width and height, you bizarrely claimed that it wasn't, in clear contradiction to reality. At any of those steps, an appropriate response might have plausibly included the phrase "thank you", or at least "OK, but...". Instead, it's been one one redirection after another. I tell you one thing (*correct* advice, it should be noted) and am immediately hit back with a counterclaim. Basically, you've been a jerk from the beginning to end of this process and frankly I don't really want to work with you. Your contributions aren't valuable enough to be worth the emotional effort. Some jerks can prosper in collaborative projects because of the utility of their work (c.f. Melchior, Mathias, maybe me if I still count as a core developer). You aren't in that league, honestly, and you might find that a little humility would produce better service. But, all that being said: yes, you found a bug. The spans-are-too-wide problem* is caused by a sign bug when calculating the "extra" amount to distribute between spanned cells. Fixed in CVS. Andy * As distinct from the layout-is-too-narrow problem you reported earlier, or the "there are no spans" non-problem you originally reported. - 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] spanning multiple columns in gui layout
John Denker wrote: > Yes, I tried it. It looks terrible. > > It still appears to be miscalculating by a factor of 3 the required column > width. A factor of 3? Dunno, it looks fine to me, and I can verify that it fixes your problem with shrinking columns. Whether you choose to believe me or not is, of course, up to you. I suspect this is a now a new bug report. Can you explain this problem for me (maybe with a screenshot or two) so that I can help you? Or are you happier to sneer and snipe and make me beg for details? Basically: check the ego at the door, John. Most of us here would actually like to help you (evening if helping you means encouranging you to use the layout manager instead of 1984-era hand-drawn dialogs). Spitting in our faces and playing ridiculous semantic games just isn't productive. Andy - 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] spanning multiple columns in gui layout
John Denker wrote: > Andy Ross wrote: > > Here's the problem. You're giving your dialog a fixed size, then > > asking it to display something that doesn't quite fit. > > On my syste, with the default style, it should fit with room left > over. The working version makes this particularly clear. > > Why do you say it doesn't quite fit? Because I ran layout-test and watch it shrinking the size of the columns, then wondered why and discovered that you are giving the dialog an explicit size. That's just plain wrong in a layout dialog, unless you are attempting to do something fancy. An explicit width means "make the dialog exactly this big". If you happen to give your table more content than it can fit, it takes the difference and subtracts it equally from each column. The "working" version just happens to look better because of the details of your layout; the extra width gets sunk into columns that happen not to need it, instead of spread evenly across the colspan range. The table code doesn't understand any of that and just shrinks all columns equally. Had you picked different strings to put in those columns, it might have looked equally bad or worse. Have you actually tried removing those two lines yet? I promise you it works. Andy - 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] spanning multiple columns in gui layout
John Denker wrote: > Compare: >http://www.av8n.com/fly/fgfs/weather.xmlworks >http://www.av8n.com/fly/fgfs/weather.xmlbroken > > The difference between them is simple, and is attached below. > The working file contains a working colspan. The broken > file contains a second colspan that significantly distorts > the table. Here's the problem. You're giving your dialog a fixed size, then asking it to display something that doesn't quite fit. So it's shrinking the columns evenly, and things look wrong: > > > weather > 840 > 570 Putting one word in each column only happens looks better because of the details of your layout and the length of your strings. Let the layout manager pick the size, that's what it's there for. Just remove the width and height lines and all will be well. Andy - 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] spanning multiple columns in gui layout
John Denker wrote: > Yes, the feature is documented, and there is some code to > implement it (in GUI/layout.cxx) ... but it doesn't work > reliably. Sometimes it works, sometimes it doesn't. Can you provide a case where it doesn't? I can't promise or prove the lack of bugs, only fix the ones that are reported. > Grep tells me there are zero instances of it being used in > CVS/gui/dialogs. Your grep, apparently, is lying to you. Check autopilot.xml, it uses a rowspan for the "Speed with XXX" entries to vertically center the input field between the two lines. Andy - 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] Programming "Style"
Thomas Förster wrote: > which reminds me of: > The Zen of Python (by Tim Peters) > Probably a bunch of good ideas for every language. Yup, great advice. Pity python forgot about it: > There should be one-- and preferably only one --obvious way to do it. > If the implementation is hard to explain, it's a bad idea. Read and internalize those, and then teach list comprehensions to a C programmer. The more curmudgeonly I get, the more I think everyone should just be coding in Nasal... Andy - 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
Ralf Gerlich wrote: > Maybe that's a dumb question (which would be embarassing, because I > typically think of myself as a good C++ programmer), but why use a > reference in the return type anyway instead of the "real thing"? If a > copy is created anyway, the "&" doesn't have any advantage, or am I > missing something? References can be lvalues, so it's possible to write functions whose returned valued can be assigned. The examples are usually pretty academic, but consider a sparse 2D array with a method like int& element(int x, int y); You can use this thing as element(3, 4) to get the value, but you can also use: array->element(3, 4) = 12345; to *set* the value. Cute, huh? And utterly worthless. Sane code would just use a set_element() function and be done with it instead of using a design element that even good, productive programmers don't always recognize. The older I get, the more C++ looks like a terrible, terrible mistake. Andy - 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] spanning multiple columns in gui layout
John Denker wrote: > Here's the scenario: Suppose you have a nice table with rows and > columns. Most of the rows have many narrow columns, but one or two > rows have a lesser number of wider columns. The existing layout > manager has no idea how to handle this AFAICT. Use the "rowspan" and "colspan" properties. Check Docs/README.layout for details. Andy - 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: building 0.9.11-pre1 on ppc
Ladislav Michnovič wrote: > 2007/5/24, Andy Ross <[EMAIL PROTECTED]>: >> Can you provide more details about your platform? I was under the >> impression that OS X on PowerPC used the __ppc__ symbol, but I don't >> have a box to test against. If your compiler is gcc, can you post the >> results of: >> >> echo | gcc -E -dM - > > Yes I can. I'm building RPM on SUSE Linux. Ah, OK. Apparently GCC/linux and the OS X folks picked a different set of architecture symbols. Should be fixed in CVS (both branches, and in the Nasal upstream). Andy - 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] AN-225 patch
Joacim Persson wrote: > README.yasim says the "semi-deprecated" transition-time is "Time in > seconds to slew through input range." I'm not quite sure what it is, > but it's not that. ;) It's coded to assume that the "input range" is 0-1. It was really written for landing gear. If you want to model hydraulic delays (which is what I think is happening here) you'd probably be happier with some Nasal anyway. Thus the "semi-deprecated" note: this feature still works as intended, but there are far more robust ways to solve the same problem in the modern environment. Andy - 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: building 0.9.11-pre1 on ppc
Ladislav Michnovič wrote: > Hello. > Compilation on ppc machines crashed on unknown CPU in > simgear/nasal/naref.h file. > I've changed __ppc__ to uppercase and detection works fine. Can you provide more details about your platform? I was under the impression that OS X on PowerPC used the __ppc__ symbol, but I don't have a box to test against. If your compiler is gcc, can you post the results of: echo | gcc -E -dM - Thanks, Andy - 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] OSG yasim-test build error - Possible Solution
> Oh, wait a second: I now see you are talking about the header (.hpp) file, > whereas I was referring to the (.cpp) source file, Gear.cpp. You are right > that the former (the hpp) contains (only) the SGmaterial reference. The > latter, the Gear.cpp source file is the one containing the additional SimGear > include, as shown in the url to the cvs log in my previous mail. Indeed. Nonetheless, from a build just completed: $ ldd ./yasim libdl.so.2 => /lib/libdl.so.2 (0x2ac79e774000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x2ac79e878000) libm.so.6 => /lib/libm.so.6 (0x2ac79ea78000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2ac79ebf9000) libc.so.6 => /lib/libc.so.6 (0x2ac79ed07000) /lib64/ld-linux-x86-64.so.2 (0x2ac79e657000) Those extra SimGear libraries don't require anything from OSG, except perhaps the compile-time headers. Are you doing anything fancy like building SimGear as a shared library? Andy - 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] OSG yasim-test build error - Possible Solution
Durk Talsma wrote: > Looking at the CVS browser, it seems like this dependency on SimGear > was added on January 17, as part of a patch contributed by Maik > Justus: Sorry, but I honestly don't know what you're looking at. There are no SimGear includes in the HEAD of Gear.hpp in my tree. There is no revision 1.8 of that file in the cvs log AT ALL. When I do: cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs/FlightGear-0.9 co source/src/FDM/YASim/Gear.hpp ... I get a file with no SimGear headers at all, just a "class SGMaterial;" declaration at the top. This is bizarre. Curt? Are there separate trees for this stuff? Andy - 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] OSG yasim-test build error - Possible Solution
Durk Talsma wrote: > Gear.cpp includes: > #include Not in CVS it doesn't. It makes a type declaration for "class SGMaterial" so it can pass a pointer to it only. Do you have some local changes or patches from someone else applied? Andy - 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] OSG yasim-test build error - Possible Solution
Durk Talsma wrote: > Back in January, right before my Canadian adventure, I reported a > compile error related to yasim-test. [...] I found that the following > modification to src/FDM/Yasim/Makefile.am works: > > [...] > > I basically added the -losg* linker directives to ensure that the correct > libraries are known to the linker. This looks wrong to me. The yasim command line tool doesn't require anything from the FlightGear tree at all, and only the XML parser from SimGear. So far as I can tell, it builds for me without problem. I think you may have a library pollution issue; maybe a local change to one of your SimGear libraries is suddenly pulling in OSG code where before it stood alone? Andy - 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] New Nasal in CVS
Harald JOHNSEN wrote: > I've added this to the two file where func is used (seen on the interweb) > /* Try to get a reasonable __func__ substitute in place. */ > #if defined(_MSC_VER) > /* MSVC compilers before VC7 don't have __func__ at all; later ones call it > * __FUNCTION__. */ > #if _MSC_VER < 1300 > #define __func__ "???" > #else > #define __func__ __FUNCTION__ > #endif > #endif What version of the toolchain are you using? I was under the impression that that had already been vetted against MSVC, but might be wrong. > compiles ok, but link fails > Some functions defined in thread-posix.c (and used) are not defined in > thread-win32.c > I've forced the use of thread-posix, compile and link is ok now. That sounds wrong, a pthreads library shouldn't be required on windows. Can you provide the exact linker error you are seeing? Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal iolib & security
Stuart Buchanan wrote: > Functionally, it seems reasonable to force all IO access through a > wrapper .nas file in $FG_ROOT/Nasal that could attempt to restrict > dangerous activities. This is actually possible, albeit obtuse. In the existing io.nas file (which currently adds the soft-coded readfile() function to the module) you can write a loop that inspects all the local variables for functions (you can get the local variable hash as caller(0)[0]), and replace each one with a wrapper version that checks the calling file (again using caller()) against a "blessed" list. Then the problem becomes one of maintaining the "blessing" rules such that they are secure. We can try to handle the issue from the other side too: identify all the spots where strings come in from outside the $FG_ROOT directory and audit these to make sure they can never be used as a script. One *really* easy way to do this would be to override the compile() function in globals.nas with a non-functional version. But compile() is really useful in practice... Another option, obviously, would be to just disable the io module again. But I enabled it this time because a new release is still well-off, and this seemed like a good time for experimentation. Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] New Nasal in CVS
A big heads up. I just updated the Nasal interpreter to sync it with Nasal CVS: > Sync with Nasal CVS (soon to become Nasal 1.1). Notable new features: > > Nasal now supports calls to "subcontexts" and errors can be thrown > across them, leading to complete stack traces when call() is used, > instead of the truncated ones we now see. > > Vectors can now be concatenated using the ~ operator that used to work > only for strings. > > Better runtime error messages in general due to a fancier > naRuntimeError() implementation > > A big data size shrink on 64 bit systems; the size of a naRef dropped > by a factor of two. > > "Braceless code blocks" have been added to the parser, so you can > write expressions like "if(a) b();" just like in C. Note that there's > still a parser bug in there that fails when you nest a braced block > within a braceless one. > > Character constants that appear in Nasal source code can now be > literal multibyte UTF8 characters (this was always supported for > string literals, but character constants were forced to be a single > byte). > > New modules: "bits", "thread", "utf8" and (gulp...) "io". The bits > library might be useful to FlightGear, the utf8 one probably not as > Plib does not support wide character text rendering. The thread > library will work fine for spawning threads to do Nasal stuff, but > obviously contact with the rest of FlightGear must be > hand-synchronized as FlightGear isn't threadsafe. The io library is > no doubt the most useful, as it exposes all the basic stdio.h > facilities; it's also frighteningly dangerous when combined with > networked code... This almost certainly broke something, somewhere. Please be on the lookout for anything that looks like it might be an interpreter bug or new behavior. Likewise, let me know if any platform builds broke -- at the very least, MSVC project files are going to need to be updated for the new files. Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textranslate Step and Scroll
I wrote: > The patch itself looks sane and easy. But I think I agree with > John, this is a workaround for a design flaw in the step animation > that we should just fix. Nope, it turns out we really do want truncation. The reason is that the input property to the animation, at least in Ron's case, isn't a single digit, it's the whole value. So you want to pass in the floating point value 29.92 and a step of 10 and get back 2, and *not* round up to 3. You want truncation for everything but the final digit, where rounding is more appropriate and the bias value is a useful workaround. So if there's a design flaw here, it's at a higher level. Maybe what's really needed is a "digit extractor" animation instead. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textranslate Step and Scroll
John Denker wrote:
> Ron Jensen wrote:
> > The tag effectively truncates the property, 29.9199
> > becomes 29.91, so a (3D) readout reads off one number.
> >
> > I am proposing an new tag, , that will act like but be
> > applied before and
>
> While the tag seems reasonable enough, the *first* step
> should be to repair the feature so that it performs
> rounding rather than truncation.
This subject came up on the IRC channel (which increasingly seems like
the only contact I have with you guys -- I'm not dead, really!) and
Ron sent me his bias patch for commit.
The patch itself looks sane and easy. But I think I agree with John,
this is a workaround for a design flaw in the step animation that we
should just fix. Can someone (ideally people who, unlike me, know
where to look for lots of step animations) try this completely
untested patch to simgear/scene/model/animation.cxx? It just
rewrites apply_mods() to do rounding (and IMHO to be clearer and
simpler):
--- simgear/scene/model/animation.cxx 2 Feb 2007 07:00:54 - 1.63
+++ simgear/scene/model/animation.cxx 7 Feb 2007 18:18:32 -
@@ -107,27 +107,14 @@
static double
apply_mods(double property, double step, double scroll)
{
-
- double modprop;
- if(step > 0) {
-double scrollval = 0.0;
-if(scroll > 0) {
- // calculate scroll amount (for odometer like movement)
- double remainder = step - fmod(fabs(property), step);
- if (remainder < scroll) {
-scrollval = (scroll - remainder) / scroll * step;
- }
-}
- // apply stepping of input value
- if(property > 0)
- modprop = ((floor(property/step) * step) + scrollval);
- else
- modprop = ((ceil(property/step) * step) + scrollval);
- } else {
- modprop = property;
- }
- return modprop;
-
+if(step == 0)
+return property;
+double bias = (property > 0) ? 0.5 : -0.5;
+double result = step * (int)(bias + (property / step));
+double diff = result - property;
+if(fabs(diff) < scroll)
+result = property + step * (diff / scroll);
+return result;
}
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] small bug in YASim-gears
Maik Justus wrote: > there is a minor bug in YASim in the gear code. The sfric and dfric > tags in the aircrafts .xml are ignored. I didn't even know those were tunable. Actual tires have a very narrow range of friction coefficients, except for special cases like "knobby" off-road tires or special surfaces like ice or water. Did I add this code? But I agree, taking those lines out looks right to me. > Maybe this helps to solve the slipping of parked aircrafts (by > adjusting sfric). Very unlikely. The slipping is a numerics effect, not a modeling one. The only way to get the gear jitter to produce a stable solution over time is to push the coefficients *down*. But that will produce more slipping, not less. The solution to this problem is a rewrite of the static gear friction to use a damped spring model around a "stuck" point. But that's hard for the case of rolling gear. Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal hash question
Josh Babcock wrote:
> foreach(light; lights) {
> propertyPath = 'some/path/'~light;
> # do magic to the hash lightNodes here
> # So that a node linked to propertyPath
> # with a key of light gets added to lightNodes
> }
The hash/vector index expression is an lvalue that can be assigned as
well as inspected. So it's just:
foreach(light; lights) { lightNodes[light] = propertyPath; }
Andy
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal problems on dual core cpu/64 bit linux
Torsten Dreyer wrote: > Is there an issue with 64 bit linux or dual core/smp that I am not > aware of? Nope, I'm running FlightGear on a x86_64 Ubuntu Edgy on a Core 2 Duo without problem. As Melchior pointed out, this was just a plain old script bug. Note that FlightGear's main loop (which includes all possible Nasal paths) is single-threaded. So whatever synchronization bugs might live in the interpreter, we wouldn't be able to exercise them under the current architecture. Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPL Violation?
Arnt Karlsen wrote: > ..since "redlinedit"'s eBay site in no way "contains a notice placed > by the copyright holder saying it may be distributed under the terms > of this General Public License." Here is your confusion: "redlinedit's eBay site" is not FlightGear. It is copyrighted by redlineedit* not us, and is not licensed under the GPL. The GPL covers the software, not the page used to advertise it. Your interpretation would make *any* advertisement of GPL software illegal if it wasn't done by the copyright holder, and that's clearly non-sensical. Take a look at the ad banners on Slashdot, for example. Andy * Except, arguably, for the screenshots. But even there, I think you could make a very valid fair use argument that as long as your distribution is licensed, making screenshots for the purpose of advertising is fine. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPL Violation?
Martin Spott wrote: > I'd say this is by far the smartest comment on the topic. Don't get > your/our hands dirty and in case of doubt let others take action ;-) Are you a professional troll? It seems like every time I post, you end up coming back with some ridiculous snark. Stop it, now. It's offensive and uncalled for. I don't care if you want to agree with me or not, but if you can't act like an adult, then please go somewhere else. Everyone else here manages to disagree without acting like a four year old... Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPL Violation?
Arnt Karlsen wrote: > ..moot, he disregards the GPL _completely_ and is hit by copyright > law, plus possibly for fraud, in representing himself as a "fully > licensed reseller." Abiding by the GPL, he would have been. I should jump in here: your logic is flawed. You might just as well argue taht he *is* a fully licensed reseller because he in in 100% compliance with the GPL. You are taking GPL incompliance as a postulate and then using that to argue that the "fully licensed" clause is a violation of copyright law. But you need to *prove* that incompliance first, otherwise this argument has no meaning. Seriously, folks: this is shady, but it's not illegal. The only problem I can see (which isn't itself a GPL violation) is that he doesn't recognize the copyright holders in the auction. Likewise, we should be sure that he's distributing the full source code (or the required written offer) along with the packages he offers for download. And relax, everyone: he's certainly not getting rich, and he's distributing FlightGear to people who might otherwise not have noticed us. That's a *good* thing for us, ecologically. Just send him a nice note asking that he put a link to flightgear.org in the auction, and make sure he's distributing the source. If he refuses, then let eBay know that he is distributing software without the permission of the copyright holder and refusing to accept the (very reasonable) terms we ask for. And let eBay make the decision as to whether this is legal or not. Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] What does control gear/gear[0]/position-norm property in A-10?
> I whish there were more NASAL tutorials around. This page is a little out of date, but it should be linked to from wiki.flightgear.org (where there is lots more good information): http://plausible.org/nasal/flightgear.html It has reference docs on most of the core interface, but not the more elaborate nasal extensions; interpolate() is in there, for example. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG Performance on WIndows
Frederic Bouvier wrote: > Sorry, but I only understood that Mathias is not willing to backport > new features. He never said no one should do. It's possible that I misinterpreted, and maybe Mathias would like to clarify. But FWIW I thought he was pretty unambiguous: : I would like to restrict that a bit. For bugfixes and non : developers this might be a good idea. But please do not develop new : features on the branch. [...] I will port changes that are checked : in to the branch to HEAD as long as these are only bugfixes. And, as I've said, I find this attitude unfair and counterproductive. And I'm clearly not alone. It's just not acceptable to break things and refuse to allow folks to see the fixes on their (working!) branch. Sure, "someone" could do it if they wanted. But hiding behind "collaboration" seems unfair to me, as if you guys are saying "You want it to work? Fix it yourself." The content developers didn't break it. Look, this whole argument will go away if OSG starts working for everyone. If you want the complaints to stop, then get it fixed. If it's not, I can guarantee they're only going to get worse over time. I'll just say it: the OSG port is, as of today, an unmitigated disaster that should *never* have been applied to CVS in the state it is in. Apologies in advance if that offends someone. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG Performance on WIndows
Douglas Campos wrote: > but content developers can't just stick with plib branch? afaik > we'll only making the "porting work" at trunk, right? No, they can't; not if (by Mathias's suggestion) new features are added only to the head and not to the plib branch. See his post a few messages up. That issue is, in fact, exactly what got me into this thread. I'm fine with maintaining two branches in parallel while one stabilizes. But cutting off the working branch when the new one is still stabilizing is just wrong. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG Performance on WIndows
> People apparently got used to the state that FlightGear typically > has a CVS tree that you can compile at the end of a development day > and 'fly'. Remember that people doing aircraft models and scenery are also "developers", and need to be able to run the development version to do their work (for example, to pick up bug fixes and new features -- this kind of back and forth happens every day on the IRC channel). The CVS head isn't just for code jockeys like us, and treating it like it is is a sure way to cheese off our content developers, as witnessed by this thread. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG Performance on WIndows
Curtis L. Olson wrote: > Andy Ross wrote: > > Look, the points wasn't that plib is great. The point wasn't that > > OSG has no advantages. > > I'll just jump in here with a couple quick comments. OSG does have > advantages that we should be able to realize pretty quickly, it is not > completely without advantages. Let's have a little patience before we > jump too far to conclusions. I, er, don't think you interpreted what I wrote correctly; check the double negative. :) And sure, patience is good and panic is bad. But at the same time: recognize that patience is limited, and there's a point at which panic is justified. It's already been almost two weeks since the OSG code started going in, and there still remain many issues. Performance under windows (but not linux, at least not my box) has suffered a serious 20-50% regression that can't be ignored. Several aircraft look just awful right now due to missing features. FlightGear can't be built easily by non-coders (at least those who can apply a patch to a CVS checkout) and can't be run at all on a system with OSG already installed (again, by a regular user). These are all regressions, not just bugs. They are things (important things, often) that used to work. Now, no one understands better than I do that you can't improve things without breaking stuff sometimes. But there's a limit. Stuff that's broken needs to be fixed, and it needs to be fixed very soon. The masses are restive out there. Honestly: I would have suggested putting the OSG code (and not the plib fallback) into a CVS branch and working on it as an experiment for a while. Doing in on the head* was too much breakage to absorb cleanly. Andy * And especially then trying to refuse new features on the plib branch, which is what got me into this fight. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG Performance on WIndows
Ooh, it's a bona fide flame war. :) Look, the points wasn't that plib is great. The point wasn't that OSG has no advantages. The point was that we've taken working software and regressed its feature set pretty severely, and that's a serious problem that needs to be fixed now. Stopping development on other parts of the system simply because you want to advocate OSG over plib isn't acceptable IMHO. If it's not ready yet for public consumption by the other developers (and, judging especially from the folks on IRC, it isn't) then it needs to live in a development branch until it *is* ready. This is too much, too soon, and with too little warning. > > + I don't like the OSG build system at all. > > Well every one of us should be allowed to have personal preferences, > don't we ? ;-) Stop flaming. You cut out all the text where I explained *why* I don't like the build system. Building out of tree, en/disabling shared library support, and installing into a custom prefix aren't "personal preferences." They are concrete software features, ones that I happen to use to build FlightGear, and ones that are lacking from OSGs makefiles. There are other nits too, like the fact that it wants to pass either "-g" or "-O2" to gcc, and not both, or the fact that "make static" only works for the example programs. > Certain things in FlightGear simply don't work with the latest PLIB > release My point was that FlightGear will build and run successfully with a released version of Plib that you download from www.plib.org. This is not true of OSG. There is currently *no* version of OSG you can get from www.openscenegraph.com that will work with FlightGear. This is especially problematic because OSG ships only as shared libraries. If you happen to have a release version already installed on your system, then you can't build or run FlightGear *at* *all* without hacking with your runtime linker configuration. > I accept that you don't like the move to OSG maybe simply because > it's not your invention, I'll see your ad hominem and raise you three: You just don't like YASim! Thbbt! Neener neener poo poo! Flame on, I guess, Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG Performance on WIndows
> I would like to restrict that a bit. For bugfixes and non > developers this might be a good idea. But please do not develop > new features on the branch. I know how many problems this will > give. And to be honest, Olaf I believe You know what I am > talking about ... No offense, but the proper way to prevent people from wanting to use the Plib branch is to *fix* the OSG code. Whining about it is kinda bad form. People want to use the plib branch because it works better than the OSG branch, and they shouldn't be denied features just because it makes developers' jobs harder. This is a big, disruptive change, and I'm sympathetic to you, really. YASim and Nasal were big and disruptive too. But so far, OSG has produced literally zero benefit for anyone. People's experience has been anywhere between "it seems to work OK" to "everything is slow and ugly" to "I can't get it to build!". For myself: + I don't like the OSG build system at all. Getting the equivalent of --prefix requires 5 non-standard environment variables to be set, and it doesn't support building out-of-tree. + It's freakin' huge! Takes longer to compile than the rest of FlightGear put together. + C++ shared libraries (12 of them). Enough said. I tried the "make static" option, but it didn't install the libraries properly. And the biggest complaint: + No released version of OSG works with FlightGear, nor does their CVS head. Technically, we're porting onto a *fork* of OSG right now. We never did this with plib: if we needed features from CVS plib, we'd still have compatibility code in place that work work with their releases. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] What does control gear/gear[0]/position-norm property in A-10?
> I'm new to aircraft model animating, I'm trying to understand what does > control the gear/gear[0]/position-norm property in the A-10 aircraft ... This is a property output from the YASim FDM. In the A-10-yasim.xml file you will find the following line in the nose gear tag: This instructs YASim to place the result/output value of the "EXTEND" axis of the gear object (not the same as the axis input -- it can be scaled or offset, and interpolated through a transition-time period) into the specified proprty. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Linking 'fgfs' on FreeBSD
Martin Spott wrote: > Think of some application that needs - just as a stupid example - > only functions from libosgText but none from libosgSim ? Actually, here's a better explanation: let's call that application "FlightGear" and say that it requires functions from osgUtil, osgSim and osgDB, but not osgText. It should be able to link successfully without referencing osgText, right? Except that, as you discovered, it doesn't. That OSG insists on shipping C++ shared libraries is dumb enough. That they broke it down into 12 inter-dependent parts is just ridiculous. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Linking 'fgfs' on FreeBSD
Martin Spott wrote: > I guess the intention is to allow developers to link only the libraries > whose functions they actually call. Think of some application that > needs - just as a stupid example - only functions from libosgText but > none from libosgSim ? What would be the benefit of that if libosgText requires libosgSim anyway? It's just dumb, no one else does it, and it implies to me that the OSG developers don't know much about how to write shared libraries. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Linking 'fgfs' on FreeBSD
Martin Spott wrote: > I had to make the following change in order to get the 'fgfs' binary > linked on FreeBSD. 'libosgSim' apparently references some functions > like "osgText::readFontFile" which areimplemented in 'libosgText' Which begs the question: why on earth does OSG insist on installing twelve (12!) distinct, inter-dependent shared libraries instead of just one? That's a huge waste of runtime linker cycles, and a big pain for developers. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flightgear CVS and amd64
Didier Fabert wrote: > anybody have a runable flightgear CVS with a 64bits processor (linux) ? Yes, CVS as of yesterday afternoon on Ubuntu Edgy amd64. The OSG build was, er, painful to get working in my setup (I like to build out-of-tree into a custom --prefix). But it works. > i hear that nvidia driver must be on 32bits . is it true? No. They have versions for both architectures. With a little care (or the appropriate distro package), you can even have them installed simultaneously to run 32 bit OpenGL apps (Google Earth) on a 64 bit desktop. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reviews etc.
Jim Wilson wrote: > Andy Ross wrote: > > There's actually nothing wrong with selling free software for money, > > The first statement there is not exactly true. Take another look at > the GPL. At the prices he is charging for "shipping and handling" > it'd be fair to call that a legitimate distribution fee. No, it's correct. The second paragraph of section 1 of the GPL v.2 reads quite plainly: You may charge a fee for the physical act of transferring a copy There is no limitation placed on what that "fee" is, it could be anything. Obviously it is limited to a fee for a service, as the GPL precludes selling a "license" or other IP rights. But there is no requirement here that the fee be "legitimate". A fee is a fee, it's a price that someone charges for something, and the seller gets to set the price subject only to market demand. What I think you are confusing it with is this language from section 3b: You may copy and distribute the Program [...] in object code or executable form [...] provided that you also [...] b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code But that languages is specifically for *compiled* distributions. You can sell it for whatever you want, but *if* you sell it without the source code, you need to make sure that the user can get the source code easily and cheaply. In this case, the guy says the source code is in the package. Really, there is nothing legally wrong with what this guy is doing, and the only ethical glitch is the ambiguity of not identifying it as GPL software in the advertisement (which he said he'd fix). I guess I fail to understand why so many people get upset about this sort of thing. If there was significant money to be made selling free software, wouldn't we all be, y'know, making some? :) Give him a break; I can all but promise you he's not getting rich on our work. Think of it as evangelism: distributing FlightGear to people (and there are many!) who aren't comfortable with or capable of downloading (or even discovering) giant software packages from the internet. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reviews etc.
Lee Elliott wrote: > Melchior FRANZ wrote: > > Weird: > > http://cgi.ebay.com/FLIGHTGEAR-2006-PROFESSIONAL-AVIATION-FLIGHT-SIMULATOR_W0QQitemZ160036333084QQcmdZViewItem > > It is actually FlightGear - this person appears to have > re-packaged FG i.e. basic system with most of the more complete > aircraft included i.e. > > I found no mention that this stuff is covered by the GPL or if > the source-code is included/available, which I believe is a > requirement of the GPL. This subject came up on IRC a few days ago. I sent the guy a nice email explaining the requirements, and pointing out that the easiest way to do this is to explain in the auction that this is an open source project hosted at www.flightgear.org. He replied that he already includes the source code and GPL in the package, but that he would be happy to add a flightgear.org link to the auction. I haven't gone back to check. There's actually nothing wrong with selling free software for money, so he's basically fine. It's just slightly misleading to do so without explaining that it is also freely available. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Contribute with fixes
Trasca Virgil wrote: > I am intersted in contributing with some bug fixing to flightgear > project. How should I start for that? To start with, you need to find some bugs you want fixed. :) If you have a CVS version built and running (this is step one, obviously), you should have no trouble finds a few misfeatures that you hate. Then just start pulling things apart to see how they work, ask questions here or on the IRC channel, and have fun. Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model for the F-15
Martin Spott wrote: > Andy Ross wrote: > > flying.toaster wrote: > > > Is there anywhere a list of work in progress just to avoid duplicates? > > > > Even if there were, the best advice would be to ignore it. :) > > Teamwork is not one of your favourites, is it !? ;-) In what way is refusing to work on a task in deference to someone else who will never finish it "teamwork?". Teamwork requires that people actual *do* what they claim to be doing. This point was, I think, fairly well explained in the following paragraph to which you conveniently did not reply. :) Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model for the F-15
flying.toaster wrote: > Is there anywhere a list of work in progress just to avoid duplicates? Even if there were, the best advice would be to ignore it. :) This is a volunteer project done (mostly) for the enjoyment of the developers, and as such many of the subprojects that are announced here end up abandoned or stillborn. Just do your best, try not to blatantly step on anyone's toes, let people know what you are doing, and don't worry too much about duplicated work. Think of it as a darwinian development model: the fittest work survives. > I want to release the models with a license that would prevent any > commercial or military use. > > I think Creative Commons can do that but if you know anything else > better ... Note that this will preclude shipping it with FlightGear, which is released under the GNU GPL. See the COPYING file in your data directory to see if those terms are acceptable to you. If not, you will have to distribute the files yourself, unfortunately. FWIW, the Creative Commons license (like the GPL) does not prohibit any particular users of the work either. It only covers the restrictions that the recipient can place upon further distribution. Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] memory and smp
I wrote: > Finally, please make sure you remove *all* traces of FlightGear and > SimGear from you system before doing a Sorry, an editor goof pasted the first sentence of this into the wrong place and dropped the rest of the paragraph. Should have read: Finally, please make sure you remove *all* traces of FlightGear and SimGear from you system before doing a build from CVS. Version skew problems are probably the single most reported build error we see. :) Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] memory and smp
Finally, please make sure you remove *all* traces of FlightGear and SimGear from you system before doing a Durk Talsma wrote: > Lou Sanchez-Chopitea wrote: > > I have assembled a box based on a Tyan MB with two Athlon MP 2000+ > > with 2GB of ram, running Fedora Core 5. I get segfaults in both > > the yum installed FG and a local version built from sources. Has > > anyone encountered problems (or success) on dual processor > > systems? > > About two weeks ago, I posted a valgrind error log on the list, which you can > find here: http://durktalsma.xs4all.nl/valgrind.log Note that both the X11 libraries and NVIDIA libGL implementation generate a huge stream of (apparently benign) uninitialized memory reads. You will need to filter them out if you want to get any use out of valgrind. But the general answer to your question is no: because of FlightGear's interactive nature and the performance hit from running under valgrind, we don't tend to run it on the fgfs binary*. So there are almost certainly some good bugs living in there for someone with the energy to find them. * Although some subsystems can be run independently. I did a valgrind round on the YASim solver a while back and plugged a few leaks, for example. Also, what video hardware and driver are you using, Lou? Note that there is a known issue with the X.org indirect OpenGL drivers that causes a crash on startup (not that indirect rendering will work anyway, but if you are seeing the crash you may not know this). As to SMP, it works fine. I'm now building and running FlightGear on a Core 2 Duo in 64 bit mode (Ubuntu Dapper amd64) without problems. FlightGear makes very poor use of the second CPU (our only extra thread is just doing I/O), but it runs correctly. Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] coding style...
Syd wrote: > Hi guys , I'm not sure what indentation style you are referring to , > and I have warned everyone it's been a long time since I have done > any programming The purpose behind coding styles is to make the code easy to read. Melchior wasn't talking about anything specific, just the general rules that all styles adhere to. Most important in this case is indentation, your submitted file had none. Code in all modern programming languages has a recursive structure; some code blocks live "inside" other code blocks. It is a long-standing tradition that this structure be reflected in the indentation of each line of code: + "Inner" structures should have more whitespace at the beginning of the line than their enclosing blocks. + Lines that are "siblings" in the structure of the file should have exactly the same amount of whitespace. If you follow no other rule, follow this one. It's common to every sane programming style out there. Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim feature request
Maik Justus wrote: > You can add more than one control to one gear. If you specify more > than one, the sum of them is used. Normally used for trimming or for > the "no-pedals-patch" for the bo, which adds a fraction of the > collective input to the pedals. But there's still one STEER input axis per gear, which was the source of the question, I believe. Yes, you can obviously sum multiple property inputs to that axis. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim feature request
Lee Elliott wrote: > The real a/c has steering on both front and rear sets of wheels > so that it can make a crabbed landing and this is where the > first aspect of the problem lies - there only seems to be a > single STEER control axis available. No, one per gear. You can map them to different properties. For example, map the rear gear to /controls/flight/rudder, but use the src/dst mapping to invert the sense. > The second aspect of the problem is that I can't find a > reference property to use. Perhaps there's already something > there and I'm not aware of it but even if there is, how would I > relate it to the normalised steering control input? Here, you're off on your own. The default controls only give you aileron, elevator, rudder, throttle, mixture and advance as actual control axes. You can wire up a key mapping or cockpit control to drive any other property you want, of course, or you can modify your personal joystick mappings to redirect an unused axis (the Saitek robo-sticks tend to have a few rotary dials available, for example). Note, by the way, that the STEER input is in radians (1 radian ~= 53 degrees). Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fuel & Weight dialog changes & docs
Jon S. Berndt wrote: > Hmm. I'm not sure how this interacts with JSBSim weight and balance > properties. I just got back from Keystone (AIAA Modeling and > Simulation Conference) and need to take a good look at this more > closely, but does anyone know how this interacts with all FDMs? The dialog is currently disabled for JSBSim, but the interface is really very simple. The weight interface is trivial: if you can import a point mass into the FDM from a property named in configuration file (specifically /sim/weight[n]/weight-lb at the moment) then you can use this without change. The fuel stuff is only a little more complicated; the docs are at the top of Nasal/fuel.nas. But the essence is that the tank capacity and current fill need to be settable from "script space" via the /consumables/fuel/tank[n]/... property trees, and the engines need to export their consumption (currently YASim sets a fuel-consumed "accumulator" value, but we could make this work with a flow rate with some extra nasal). Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Fuel & Weight dialog changes & docs
For those interested, the Fuel & Weight dialog just grew a new feature. The new Harrier modifications from shavlir (which are really, really nice) needed to be able to turn external stores on and off in order to correctly draw the 3D model. To do this, he wrote a nice selector GUI in Nasal and hooked to the tab key. This seemed to overlap pretty badly with the existing Fuel & Weight dialog, though, which was also intended to manage external stores from the GUI. So I spent a few hours and added the functionality to the existing dialog. This feature seems to be pretty underutilized, even for a lot of the aircraft for which it was intended. So in case anyone isn't aware of how it works, here are some docs: The F&W subsystem is entirely property driven. In your -set.xml file you add a bunch of /sim/weight[n] definitions like: Left Rear Passenger 0 300 60 This will get you a slider labeled "Left Rear Passenger" that you can tweak at runtime from the dialog. The FDM configuration would obviously read "/sim/weight[0]/weight-lb" to get the weight at runtime. You can also (this is the new feature) include a list of options and a initial "selected" property under the weight tag. This will cause the dialog to show a selectable combo box with only the named options you want: Right Wingroot 0 none none0 AIM-9L Sidewinder 155.2 AIM-120 AMRAAM 335 ALARM Anti-radar Missile590 500lb Laser Guided Bomb 606 External Fuel Tank 190 Each "opt" property has a "name" and "lbs" sub-property. You set the selected proprty to the appropriate default (in this case "none") and the subsystem code ensures that the weight-lb property is filled in correctly for the selected option. And now, the model animations can use the "/sim/weight[5]/selected" property to choose which model animations to draw at runtime. Anyway, as always let me know if I broke something or if there's something that needs to be added for it to be useful. A bunch of the existing aircraft could productively use this feature, I think. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] CVS permissions issue in base package
I hit a CVS permissions issue while commiting a new harrier version from shavlir. These are all new directories; is it possible that the setgid bit on the archive is missing? Andy cvs commit: ERROR: cannot write file /var/cvs/FlightGear-0.9/data/Aircraft/harrier/Panel/Hud/NTPS.xml,v: Permission denied cvs commit: ERROR: cannot write file /var/cvs/FlightGear-0.9/data/Aircraft/harrier/Panel/Hud/hud.nas,v: Permission denied /var/cvs/FlightGear-0.9/data/Aircraft/harrier/Panel/alt/alt.xml,v <-- Panel/alt/alt.xml new revision: 1.2; previous revision: 1.1 cvs [commit aborted]: could not open lock file `/var/cvs/FlightGear-0.9/data/Aircraft/harrier/Panel/alt/,alt.xml,': Permission denied cvs commit: saving log message in /tmp/cvsLT83vx - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim feature request
alexis bory wrote: > Well, as not being enough skilled to propose a patch to YASim, > I humbly ask Andy, and the community, to implement a tap on > each jet engine fuel arrival and make the starter start the > stopped engine (it may be allready working :) If I understand you correctly, it is. YASim engines honor their out-of-fuel properties the way you would expect. The default behavior, obviously, is to set this from current fuel state in fuel.nas, but that can be modified in a script. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2d PFD?
Curtis L. Olson wrote: > Quick question, I've been looking through existing aircraft with 2d > panels. I'm trying to find a reasonably implemented 2d PFD glass > display. We have a number of 3d cockpit options, but I need > something for a 2d cockpit. Can't you just use a 3D cockpit with an appropriate ortho matrix? Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heli simulation, new beta
Maik Justus wrote: > I would be very thankful for any review of this version. And I like > to ask Andy, to review if this version could go into cvs. This looks much, much better to me. Here's one spot that I'd like to see changed, in Model.cpp: +if (_rotorgear) +_rotorgear->calcForces(&_rotors,&_rotorparts,&_body); //it adds several torques to the body. Therfore it needs the _body as + //a parameter Yes, that's a 131 character line you wrote; I have a 1920x1200 screen and it takes of 2/3 of my horizontal real estate to read. There are a few other much-longer-than-80-column lines in there too. But that's the not actual complaint: The various calcForces() routines are idempotent by design. They should *only* calculate forces, never change state. The solver and various test code I've written actually relies on that property so it can (for example) get forces for a Surface in isolation, etc... The proper mechanism here is to fill in two 3-vectors for force and a torque which are added to the RigidBody object in the top-level Model::calcForces(). If you want to use the two-argument version of RigidBody::addForce() (for at a position), then you will need to return a slightly more complicated data structure. Also (and this is really a question about you design than a requirement to go into CVS) why do the pointers to _rotors and _rotorparts need to be passed to a method on _rotorgear? Shouldn't one of these objects contain the other ones? See PropEngine for an example: it's a Thruster object that presents a unified interface, but contains a Propeller and Engine so that they don't have to be visible to most of the Model code. Maybe the real question is: what exactly is the difference between a "rotor part" a "rotor" and a "rotor gear"? Shouldn't there just be one object? What is the abstraction here? Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Question: Is there a big mistake on the Bo
Heiko Schulz wrote: > It should be possible learning to fly a realistic flightmodel of a > helicopter with the mouse. If that were true, wouldn't helicopters have, y'know, mice? Sorry, but there is a natural tension between "realism" and "ease of use". For the case of helicopters specifically, it is very tough: real helicopters are flown (well, hovered at least) with very small control motions keyed to the pilots sense of balance and acceleration. PC joysticks and throttles have at most 7-8 bits of accuracy, which isn't even close to what a real stick/collective will need. And needless to say, we have absolutely *no* way of approximating a pilot's inertial sense. Maybe the best that could be done would be for someone to write a FCS script that helped with the stabilization and altitude mainenance for novice pilots. But that's clearly tuning *down* the realism setting, not up. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim Lockup
Jim Wilson wrote: > Using the configuration as in CVS the p51d seems to be hanging on startup. > The solver seems to succeed (after 2500+ iterations). Any suggestions on > where to start? Works for me, unfortunately. Maybe get a backtrace during the hang from gdb? Verify that the solver is using the same file from the same FG_ROOT, maybe do a rebuild from scratch just to be safe, etc.? Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim fixes from Maik / compatibility warning
Maik Justus wrote: > Andy Ross wrote: > > As I read the code, you would get 1N of force per fuselage surface > > No, it's 1 multiplied with 0.5f*rho*vel*vel*_c0. Heh, so it is. You'd think I'd remember this stuff better. Well, at least it's being checked in along with another potentially aircraft-breaking solver change. :) andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim fixes from Maik / compatibility warning
Martin Spott wrote: > This might be a typical case where someone wanted to avoid > division-by-zero cases ;-) I don't understand. Is that a snipe? Don't. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] YASim fixes from Maik / compatibility warning
Note to all YASim aircraft authors: the first fix discussed below is correct and has to be applied, but will (or at least may) have the effect of modifying the solution results of all YASim aircraft (tails are likely to be more effective: that means aircraft will be more stable on the whole, but less able to achieve high AoA's at full elevator). I'd be appreciative if everyone could take their favorite aircraft out for a spin and report changes -- some may need re-tuning. Maik Justus wrote: > Andy Ross wrote: > > Maik Justus wrote: > > > Therefore for an wing without flap, spoiler and slat [...] no surface > > > element is generated. > > > > Ah, OK. Yes, this was indeed a bug; I'm kinda shocked that we never > > noticed this before, it's been there since the code was written. > > Here it (the patch) is. Applied. > But before testing it with any YASim aircraft: I probably found > another bug in surface.cpp. For "general lift" and "flap-lift" the > effect of stall is calculated in stallFunc() resp FlapLift(). Yup, that looks correct to me. Applied. I'm not sure what the points was of the extra 1.0 in the return value; maybe a holdover from an earlier version where this function returned a scalar coefficient, and not a force? > If the fuselage is large in comparison to the wing, this amount can > be rather high. I don't think that's correct. As I read the code, you would get 1N of force per fuselage surface (of which there are maybe a few dozen across a large aircraft). The first bug is a whopper. This one is pretty much noise unless you're modeling an R/C aircraft; I'm not surprised it stayed hidden for so long. Andy - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
