Re: [Flightgear-devel] FlightGear branch, next, updated. 59d400d58b082d583959eb8c27c3155eaa301888
On Sunday 08 January 2012 05:09:07 Flightgear-commitlogs wrote: > commit 246feef85fedd548f2c198831d7d6e7e3be53e12 > Author: ThorstenB > FGNasalModelData isn't thread-safe. [...] It s*cks... ;-) It predates a separate model loader thread. If something sucks, it's an imcomplete loader thread implementation (apart from developers handing out grades without having much clue, that is). m. :-P -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata: Important note
* Jari Häkkinen -- Thursday 27 October 2011: > Didn't Franz Melchior loose some interest in fg due to a > "freedom" clash. I didn't lose interest in fg -- I only lost interest in developing for FlightGear after the project "leader" let one developer push the project in a very bad direction, and for the wrong reasons, too. (Paraphrased: "He spent a lot of time for this, so I don't want to reject it.") This has spoiled an essential part of FlightGear's foundation. Such bad engineering puts me off. There were far better solutions for the alleged problem, but cluelessness and ego stood in the way. It wasn't a "freedom clash", other than one developer having been given the freedom to destroy ... m. :-P PS: I put "leader" in quotes because for me as an Army officer, a leader is someone who *leads*. "Leadership by not leading" (and being proud of it) isn't a leadership style in my book. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.
* Durk Talsma -- Wednesday 21 September 2011:
> 1). Is there a 1 to 1 correspondence between the value of the /sim/aircraft
> property and the name of the xml file where aircraft specific properties will
> be saved in?
Yes. The path is generated in aircraft.data.init
($FG_ROOT/Nasal/aircraft.nas:348):
me.path = getprop("/sim/fg-home") ~ "/aircraft-data/" ~
getprop("/sim/aircraft") ~ ".xml";
> 2). Is there a command line option to specifically tell FlightGear which
> livery should be loaded?
No, the organization of the liveries (paths and properties) is left to the
aircraft.
Of course, one could easily standardize that and make it settable at least
with --prop:sim/...
m.
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.
* Melchior FRANZ -- Wednesday 21 September 2011: > "userarchive" simply marks what gets written to $FG_HOME/preferences.xml Whoops ... to $FG_HOME/autosave.xml. (preferences.xml was used first, but a bad idea and changed later.) m. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.
* Durk Talsma -- Wednesday 21 September 2011: > Just a quick question: Is this documented somewhere? Don't think so. Only in the code, that is. > If not, I might start a short wiki page documenting the logic behind > "archieve", "userarchieve", and the interactions with the nasal system. "userarchive" simply marks what gets written to $FG_HOME/preferences.xml and loaded next time from there (if and only if /sim/startup/save-on-exit is true). It's mainly thought for persistent GUI settings. It should not be set by aircraft, *ever*. (Needless to say that some aircraft do it anyway.[0]) "archive" is used by simgear/props_io.cxx -> writeProperties(). This function either saves a whole property tree or only those properties with set "archive" flag. This is used by fgSaveFlight(), which should only save the properties that are to be restored when a saved flight is loaded again via menu. This was broken for so long, until everyone had forgotten what "archive" was about and on which properties it should be set. It's basically what ac_state.nas does in pure Nasal, once again ... m. [0] 727-230 737-300 777-200 787 ATC B-1B CRJ-200 MPCarrier OV10 Rascal SenecaII bf109 ch53e dhc8 spitfireIX -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.
* Melchior FRANZ -- Wednesday 21 September 2011: > > > /sim/dimensions/radius-m I admit that this looks silly: why create properties that contain property paths, and not mark those properties with a flag right away, like with "archive" and "userarchive"? The reasons why I did it this way were: properties should be add-able from Nasal (setting property flags wasn't possible back then), introducing a new flag didn't seem desirable (simgear was still considered a generic library, much more than it seems to be nowadays), scanning the whole tree for just a few flags seemed undesirable, doing it in pure Nasal a quick and easy solution, and only very few aircraft needed it. Nowadays I'd probably go for proper flags. Ideally, their XML names shouldn't be hard-coded in simgear, but settable at initialization time. aircraft.data.add() could then be changed to just set that flag (props.Node.setAttribute(...)). m. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Tree Question: How to save an aircraft specific property between sessions.
* Torsten Dreyer -- Wednesday 21 September 2011: > > >
Re: [Flightgear-devel] SimGear branch, next, updated. 3ac5ff0cac4dfecc62e6deb440bb0aa309ff42c9
* Flightgear-commitlogs -- Saturday 30 July 2011: > commit 3ac5ff0cac4dfecc62e6deb440bb0aa309ff42c9 > Author: James Turner > Tweaks to HTTP code, in preparation for using it for metar - especially, > test code for proxies > -headerData << "X-Time: " << requestTime << "\r\n"; And, ironically, going to break METAR proxy service ... m. -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 63, Issue 5
Now I have to clarify: I assume Thorsten just did what he does since a while: fix bugs. Which is great. He probably either thought the bo105 is no longer maintained, or didn't know the (now obsolete?) maintenance principle. But there were certainly no bad intentions. What I'm more concerned about are those people who apparently think that maintainers (who are usually the *creators* -- who spent hundreds of hours for an aircraft) should just shut up and let others interfere without complaining. Now, you may claim that by not committing much in a long time to the bo105 I have already given up maintenance. Wrong. As long as I haven't explicitly said so and am still reachable via email in a reasonable time, I have not. Of course, I have plans to continue the bo105. But guess who makes the schedule? m. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 63, Issue 5
* BARANGER Emmanuel -- Monday 11 July 2011: > You placed them under the GPL and it's the very principle of this license. You completely miss the point. This has nothing to do with the license. It used to be an unwritten law that contributing an aircraft (or other subsystem) meant to *give*, not to give up! Contributors were supposed to develop their(!) aircraft in the repo as long as they wanted, and they kept full control. This was even true to the point that one could withdraw a once donated aircraft, and it *got* removed. (I think I don't have to give an example.) It wasn't the license that mandated it, it was respect. Something that's possibly missing nowadays. Only when a maintainer *wanted* to give up his work, someone else could take over as maintainer, or if nobody did, then the aircraft became community maintained. The license only meant that anyone could fork an aircraft, not that everyone could mess with the maintained instance in cvs/git, while completely ignoring the maintainer. Is that era of respect now over? Curt? m. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Base Package branch, master, updated. 0b8dee0f4611f0e90478f48d58951995fbe87069
* Flightgear-commitlogs -- Saturday 09 July 2011: > commit 0b8dee0f4611f0e90478f48d58951995fbe87069 > Author: ThorstenB > Date: Sat Jul 9 12:45:42 2011 +0200 > > bo105: make sim reset work when helicopter crashed > On sim reset properly "uncrash" the airframe and do not install > listeners again. The bo105 is maintained by *me*, and nobody is allowed to make commits other than adaptations to changes in the api or framework -- let's say, someone renames setlistener to set_listener, in which case an adaptation would be mandatory. This is not my invention, but was handled that way ever since I came to FlightGear in 2001, and this is also standard procedure in other projects. Patches with explanations shall be submitted to the maintainer, even by core developers. m. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [BUG] Re: SimGear branch, next, updated. c782a32076016f2c3c01b4fd437b024dc77806e9
* ThorstenB -- Monday 13 June 2011:
> [...] But I'll need some more specific details on what's supposed to
> be broken with that particular commit introducing another property flag.
Yeah, but what about the bug hunting contest?! Who wins the coffee machine?
--- a/simgear/props/props.cxx
+++ b/simgear/props/props.cxx
@@ -642,7 +642,7 @@ SGPropertyNode::trace_read () const
* Last used attribute
* Update as needed when enum Attribute is changed
*/
-const int SGPropertyNode::LAST_USED_ATTRIBUTE = USERARCHIVE;
+const int SGPropertyNode::LAST_USED_ATTRIBUTE = PRESERVE;
There's actually code depending on this, even though only once in the
repo. props.getAttribute("last") returns this value and so allows
Nasal space to assign additional, user defined property flags.
m.
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [BUG] Re: SimGear branch, next, updated. c782a32076016f2c3c01b4fd437b024dc77806e9
* Flightgear-commitlogs -- Sunday 12 June 2011: > commit c782a32076016f2c3c01b4fd437b024dc77806e9 > > Introduce "PRESERVE" flag to protect properties on sim reset. > Some specific properties need protection and shouldn't be restored to > their > original values on sim-reset. This commit is buggy. Contest opened ... m. -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Is FlightGear GPL2 and later or GPL2 only?
* kreuzritter2000 -- Friday 08 April 2011: > That's the reason why the "or later" clause is important, it can protect > your intentions in the future. Or it can be completely against my intentions. Hard to say before I read the text of the GPLv4, GPLv5 etc. I don't need a master who "protects my intentions". If I realize that the license does no longer work, then I'll change it. Note: *I* will change it. I don't see the need to let *others* change the license of my work. m. FlightGear-license paradoxon: The fewer someone has committed to FlightGear, the more he is concerned about licensing issues. -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Is FlightGear GPL2 and later or GPL2 only?
* Jari Häkkinen -- Wednesday 06 April 2011: > The GPL ideology is to keep the "or later" clause. I'm not much into ideologies. I consider both GPLv2 and GPLv3 acceptable. But I don't intend to ever (again) license anything with an "or later" clause. This is signing a contract without reading it first! Why should I allow anyone to re-license a fork of my work under GPLv4 or GPLv5?! I don't know what's in those licenses. Nobody does. And I don't consider the "or later" clause to be in the spirit of the GPL at all. (In the spirit of the FSF, yes.) Because an "or later" clause allows a fork under a license that is not compatible with what the original work is under, so that improvements in the fork cannot be ported back -- something that the FSF (rightfully) sells us as one of the advantages. You can include GPLv2 code in GPLv3 code, but not the other way around, right? So, basically, I'd be forced to switch the original work to GPLv3 to use other people's additions to it. Very much *not* in the spirit of Free Software. I'm just not naïve/stupid enough for that. m. -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Is FlightGear GPL2 and later or GPL2 only?
* Arnt Karlsen -- Tuesday 05 April 2011: > On Tue, 5 Apr 2011 21:14:03 +0200, Melchior wrote in message > > Caution: this is *not* part of the GPLv2. It's *below* the line > > stating "END OF TERMS AND CONDITIONS", and is just meant as an > > *example* for how (the FSF would like us) to apply the GPLv2. > > ..dig deep into can of worms in the 2'nd paragraph of §9 in: > http://www.gnu.org/licenses/old-licenses/gpl-2.0.html That paragraph says *nothing* that contradicted what I wrote. It rather confirms it. Sorry, you just didn't get that paragraph, it seems. Not going to waste more time on that level ... m. -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Is FlightGear GPL2 and later or GPL2 only?
* TDO_Brandano - -- Tuesday 05 April 2011: > The terms of the unmodified GPL v2 allow the relicencing by 3rd > parties with subsequent licences [citation:] > | either version 2 of the License, or (at your option) any later version. Caution: this is *not* part of the GPLv2. It's *below* the line stating "END OF TERMS AND CONDITIONS", and is just meant as an *example* for how (the FSF would like us) to apply the GPLv2. But the license is also valid if such a block is *not* added to every single code file. This is just a suggestion for "best practice". IOW: GPLv2 means GPLv2, it does *not* mean "GPLv2 or later". m. -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] KX165 - serially feeding data to increment a property value. How?
* Gene Buckle -- Friday 01 April 2011: > Using something like Leo Bodnar's joystick interface would be a good > start. I think it does work with Linux & MacOS as well as Windows. It does on Linux. The BU0836* expert for Linux is even a former FlightGear developer: http://members.aon.at/mfranz/bu0836a.html (config utility update soon to be released) m. -- 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] Stuttering at 1 Hz rate
Argh, no. Of course you want to know how much time the execution of
the function took, not the settimer call itself. So it'll be more
like this:
var orig_settimer = globals.settimer;
var globals.settimer = func(fn, interval, mode = 0) {
var where = caller(1);
orig_settimer(func {
var start = systime();
fn();
printf("(%.6f) settimer in %s:%s took %.6f s",
start, where[2], where[3], systime() - start);
}), interval, mode);
}
m.
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
* Robert -- Thursday 24 March 2011:
> Is event_mgr.cxx the right place to look at?
Well, the main purpose of the event manager is to handle
Nasal's settimer() code. So you better look for slow recurring
Nasal code. You can redefine settimer() and let it output the
time spent. I can't test that at the moment, but it will be
something like this:
var orig_settimer = globals.settimer;
var globals.settimer = func(fn, interval, mode = 0) {
var start = systime();
var where = caller(1);
orig_settimer(fn, interval, mode);
printf("(%.6f) settimer in %s:%s took %.6f s",
start, where[2], where[3], systime() - start);
}
This should show you lines like:
(10.345678) settimer in .../debug.nas:17 took 0.000290 s
(11.345670) settimer in .../screen.nas:68 took 0.004989 s
Then you search for particularly slow execution time and check
if it's in one-second intervals.
m.
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FYI: Linux 2.6.39 -> overlayfs (overlaying RW-$FG_HOME/data over RO-$FG_ROOT)
Linux users are about to get yet another toy: overlayfs. It's a
union fs that can be used to virtually merge a global read-only
FG_ROOT ("lower dir") and a personal overlaid read/write fg-data
("upper") dir, e.g.:
$ mount -t overlay -olowerdir=$FG_ROOT,upperdir=$FG_HOME/data overlay
~/fgfs/data
$ fgfs --fg-root=$HOME/fgfs/data
This works similar to FG_SCENERY or FG_AIRCRAFT, but includes
the whole data tree. The resulting virtual dir contains every file
from FG_ROOT, and every file that gets written to will be written
to the overlay dir. The resulting dir shows them merged. This
makes it easy to swap e.g. terrain texture files without creating
a mess with git-pull.
http://marcinfo/?l=linux-fsdevel&m=130080789530237&w=2
m.
PS: some more good news: "Nouveau's OpenGL Performance Approaches The
NVIDIA Driver" ... well, on *some* cards ... in *some* tests
anyway. http://www.phoronix.com/scan.php?page=article&item=nouveau_2639_flip
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Logos and licensing
* "Jon S. Berndt" : > [...] but contact the various trademark/logo owners and very > carefully inform them of the project and ask them for permission. Such requests go to the legal department, right? Their job is to protect the company, so their response will almost certainly be "no" -- tbe safest and most protective answer they can give. And it doesn't matter one bit if they have a leg to stand on legally! It's probably a gray area in many jurisdictions, but isn't what we do sculpting and painting, hence *art*? So what you end up with is an almost certain questionable "no". How much better is that than a questionable "maybe"? m.<>-- 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] Logos and licensing
* "Jon S. Berndt" : > I think that a key with all this is that none of the models will > be sold for profit. You could argue that [...] No, the key is that all the arguing will be between their lawyers and ours. Except, we don't have lawyers and can't afford them. ;-) m. -- 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] Logos and licensing
* Heiko Schulz" : > I will write some Emails to some copyright-holders this weekend > like Lufthansa, ADAC,... I'm curious to see how they react, but > I also fear a bit the answers and consequences. Severe tactical error a.k.a. shooting yourself in the foot. What if they (or some of them) are well aware of our use, but they just decided not to care, pretending not to know "officially", because it's a small, harmless, not-for-profit sim. But once you officially asked, they can no longer pretend. And the answer will be *no* in most cases. Then the silent gentlemen agreement is voided. By us! And now they *have* to take measures to protect their brand. They might think: "You idiots! Why did you have to ask?!" It's like asking a policeman if you may cross the street at red traffic light. He might have ignored you doing it. But he sure can't say "go ahead", nor can he then tolerate you ignoring his order. m. -- 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
[Flightgear-devel] FYI: http://blog.360cities.net/airplane-cockpits/ n/t
-- 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
[Flightgear-devel] "Add screenshot dialog, to select directory"
* Flightgear-commitlogs -- Saturday 15 January 2011: > commit adb57b8154a4a9dad8107c0c6633c276b43c4a20 > Author: Gijs de Rooy > Date: Sat Jan 15 22:48:43 2011 +0100 > > Add screenshot dialog, to select directory Shudder! This patch simply duplicates a lot of code that was meant to be *re-used*. A whole copy of the file dialog architecture, only to add one checkbox! A whole Nasal class for screenshot dir selectors, in addition to already existing generic file selectors? Is there no more quality control? Is every newbie now allowed to commit to core parts without any review (except post factum)? m. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Musings on optimizing Nasal code
* thorsten.i.r...@jyu.fi -- 9/16/2010 1:28 PM: > I don't think that's a valid interpretation of my results. Consider the > two cases where I achieved a significant performance gain by replacing > hard-coded structures with my own Nasal code (range animation, > distance_to() method) The distance_to() method is a pretty standard "great circle" calculation, and that's exactly its purpose. Are you sure your "faster" version does the same? Does it yield the same (numeric) results? And besides, in the visual range direct_distance_to() should be good enough, and it's certainly faster. I doubt that considering Earth curvature is *that* important for cloud distances. m. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] svginstr
* HB-GRAL -- Sunday 04 July 2010: > what is your reference for this torque instrument? This may have been the (main) reference: http://www.airliners.net/photo/Generalitat-de-Catalunya/MBB-BO-105CBS-5/0438320/L/ * Ron Jensen -- Monday 05 July 2010: > This is probably to make the needle point in a "logical" direction, so the > pilot doesn't actually have to _read_ the instrument, just see the needle is > pointed up... That was one of my explanations, but I'm not totally convinced. 100% is not a value that you usually want. And why are the instruments often mounted with 45% degree? The triple-tacho's needles normally point to the left Engine N1 somewhere down, TOT down left. Quite a mess ... m. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] svginstr
* Melchior FRANZ -- Sunday 04 July 2010: > A photo of a dual engine torque instrument used in a bo105 helicopter, > somewhere from the net. This type is also closest to the one printed > in the pilot manual, [...] Correction: The one in the manual only goes up to 110%. I took the marks from a photo, IIRC. (I haven't really decided yet which one(s) to use in the end.) m. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] svginstr
* HB-GRAL -- Sunday 04 July 2010: > what is your reference for this torque instrument? A photo of a dual engine torque instrument used in a bo105 helicopter, somewhere from the net. This type is also closest to the one printed in the pilot manual, but there are at least two other types used in bo105. BTW, the instrument is in RL mounted 90 degrees rotated to the left. Some bo105 have it rotated 45 degrees, and only few have it upright. I don't know for sure why that is the case. (It's rotated 90 deg even in the pilot manual's panel drawings!) The font in mine isn't right yet, but that's not important for an example file, where I can use only fonts that are likely installed or which I can distribute with svginstr. And the numbers aren't placed correctly either. The margin should be beveled, but that's probably to do as 3D. m. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] svginstr (was: Re: Metapost for drawing instruments?)
* Melchior FRANZ -- Sunday 13 June 2010: > The main changes in v0.2 will be [...] ... gradients and screws, so far. Drawing a screw is as simple as a.at(0, -30).screw(0.12). This updated example has been drawn by a still quite simple "torque.py" driver file: http://members.aon.at/mfranz/torque.png [81.6 kB] The dark ring is meant to be an AO shadow for the bezel. Maybe it's still a bit too dark. m. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git questions
JFTR: I *did* answer, but your provider rejected it : Connected to 207.69.189.219 but sender was rejected. Remote host said: 550 550 Dynamic/zombied/spam IPs blocked. \ Write blockedbyearthl...@abuse.earthlink.net m. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Metapost for drawing instruments?
* Alexander Barrett -- Sunday 13 June 2010:
> BRILLIANT!
Thanks. :-)
I've just committed more changes and tagged v0.1. This is backward
compatible. But the next version won't be, so if you plan to start
using the script, better wait a few days.
The main changes in v0.2 will be that there's no more bullet() and ptext(),
and that all graphics primitives are drawn at origin. All operations
lose x and y args, which are replaced by positioning commands. These
can be concatenated. All polar coordinates will be specified as (angle,
distance), never the other way around.
clock = instrument("clock.svg", 512, 512, "bo105 clock")
clock.at(0, 80).text("FlightGear", color = "red")
or instead of the former ptext() (i.e. "text with polar coordinates"):
clock.at_polar(30, 80).text("FlightGear")
And you can concatenate these positioning commands with offsets or
polar_offsets:
clock.at_polar(30, 80).offset(-5, 3).text("FlightGear")
This makes "manual" adjustments easier, as all angles are internally
mapped using the angle() method. And this angle() method can/should be
redefined to map scale values to angles, like it used to be. (That way
one can just make the tick at scale(!) value 100 red, and doesn't have
to figure out at which angle exactly that is. The angle() method knows
already.)
Confused? Excellent! :-)OK, I'll write some documentation too ...
m.
--
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] Metapost for drawing instruments?
* Melchior FRANZ -- Friday 11 June 2010: > Guess I have to answer now, as the links in that posting are no longer valid: > >$ wget http://members.aon.at/mfranz/svginstr.tar.gz# [5 kB] $ git clone git://gitorious.org/svginstr/svginstr.git m. -- 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] Metapost for drawing instruments?
* Melchior FRANZ -- Friday 11 June 2010: > Guess I have to answer now, as the links in that posting are no longer valid: > >$ wget http://members.aon.at/mfranz/svginstr.tar.gz# [5 kB] ... and that wasn't the last version, either. Please download again. Not that it has changed much, but there were some minor fixes. The arctext works now, for example. But also note that this isn't a finished package, meant for publication. I just hacked along as I needed new features, and I was really a Perl guy back than. I'll probably rewrite some parts once I do the missing bo105 intruments. That the bo105's clock doesn't look very pretty doesn't have much to do with the code. It's just that: - I used ksvg for rendering back then, and it placed numbers differently, so they are now off a bit in inkscape. - I didn't have a font where the 1 (ones) were "nose-less", so I just used a lowercase L. On the small clock scale this didn't matter much, but nowadays I'd probably search longer for a proper font, or create one with fontforge. Hint: use "fc-list" on Linux to get the names of available fonts. m. -- 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] Metapost for drawing instruments?
* Roy Vegard Ovesen -- Friday 11 June 2010: > Melchior made a Python script to generate svg-files: > > http://www.mail-archive.com/flightgear-de...@flightgear.org/msg30853.html Guess I have to answer now, as the links in that posting are no longer valid: $ wget http://members.aon.at/mfranz/svginstr.tar.gz# [5 kB] $ tar -xzf svginstr.tar.gz $ cd svginstr $ make This lets simple Python driver files (like torque.py) generate SVG files that can then be further edited in inkscape if necessary. That's a lot easier than to mess with all the ticks and arcs in inkscape, though that's possibly only because I'm not an inkscape expert. Examples (two test files, two actual bo105 files) inside. Just run "make". m. -- 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
[Flightgear-devel] outerra news
http://outerra.blogspot.com/2010/05/integrating-vector-data-roads.html m. -- 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] Bug: nav[12] selected radial
* Curtis Olson -- Tuesday 23 March 2010: > A few of us have been in correspondence with Ben Supnik from time to time, > but as far as I know, no one within FlightGear has tackled the new x-plane 9 > apt and navaid data formats. The parts of the new format that I have designed (with some input from Ben) should be functional. m. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New GUI Font
* HB-GRAL -- Tuesday 02 March 2010: > Melchior FRANZ schrieb: > > Helvetica is the default font used in HUDs (e.g. in the F16). While not > > perfect > > for that (there are MIL standards for this), > Do you mean in real HUDs? Real HUDs use a MIL standard font. Ours use Helvetica. I even tuned that for the use in HUDs, as the prior version didn't look good in tapes. I don't say that yours is worse, just that it can't be swapped without checking. And a MIL spec compliant font should be the ultimate goal, anyway. m. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New GUI Font
Just for your information ... * HB-GRAL -- Tuesday 02 March 2010: > The new gui.txf could replace Helvetica.txf. Helvetica is the default font used in HUDs (e.g. in the F16). While not perfect for that (there are MIL standards for this), it would have to be checked if an optimized GUI font is a reasonable replacement. > 'gui.txf' is a 512x512 texture file We went away from texture fonts as GUI default because they are blurry (though a bit faster to render). Back to the future? > gui.txf or a 'clone' can also be used for signage because it should > contain all the characters used in Textures.high/Signs. No. The signs are modeled after an FAA regulation. Google for 5345-44f.pdf! > And here is a changed gui/styles/anthrax.xml Why do you mess with my design?! We support multiple styles -- you can switch them through with Shift-F10. Just drop yours next to anthrax.xml. (BTW: anthrax.xml was really meant to be darker. It should be anthracite, but anthrax was so much more popular back then, hence the name. Unfortunately, I had a bad monitor. The style looked good there, but I was unpleasantly surprised when I first saw it on a good monitor ... my local version is fixed.) > or do you prefere the old pixel fonts for the GUI? I do. Not that it matters. I preferred a clean, no-nonsense property system, too ... like the majority of the coders did, btw. m. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shift key stuck once pressed
JFTR: I confirm recent sporadic keyboard misbehaviour. m. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS:data/Input/Joysticks/SpeedLinkblack-widow.xml, NONE, 1.1
* Vivian Meazza -- Friday 12 February 2010: > Tell me what Vista calls it in English, and I'll add it. You completely miss the point. "Microsoft-PC-Joysticktreiber" is a generic name that will probably be detected by plib <1.8.6 for *all* joysticks on MS Vista in German language. So why on earth should fgfs choose that particular "SpeedLinkblack-widow" js driver for *all* joysticks? We have a generic "default" js for a reason, and that one doesn't assume 6 axes and 8 buttons. The fix is to remove that entry. m. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: data/Input/Joysticks/SpeedLinkblack-widow.xml, NONE, 1.1
* Vivian Meazza -- Friday 12 February 2010: > It's an option - we're not racist here :-). We should look after everyone. OK, let me put it that way: it's a bug. Not that I really care ... m. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: data/Input/Joysticks/SpeedLink black-widow.xml, NONE, 1.1
* Vivian Meazza -- Friday 12 February 2010: > > Microsoft-PC-Joysticktreiber So we have a new default joystick on German MS Vista installations? Funny idea ... m. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] --metar and --enable-real-weather-fetch
I had looked at some research papers at that time, which were about estimating visibility from other, measurable factors. I stopped when Thomas announced his solution. My original idea was a simple formula, based on the idea that: - visibility is derived from humidity (high humidity -> low visibility due to water drops) - higher temperature decreases visibility (molecule movements) - higher wind speeds decrease visibility (more dust blown up) - higher AGL increases visibility (no dust) - smog was hard to estimate, as there was no reliable way to find out if there are bigger cities nearby (checking for distance of next airport with concrete runway of a certain minimum length might work); ground material might have an influence, but isn't very reliable All that would have to consider that METAR is weather at station level. This wouldn't have to be very accurate. Simple variability was already an improvement, while randomness was not acceptable (same weather should yield same visibility for MP or sync'ed machines). * Peter Brown -- Sunday 20 December 2009: > Of the other hand its a way to "weed out" the gamer... One of FlightGear's main goals is realism, not to weed out *any* kind of user. Maybe you are wrong here?! m. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] --metar and --enable-real-weather-fetch
* Peter Brown -- Sunday 20 December 2009: > IMHO there is no choice other than the bold solution- anything reported as > 10SM = unlimited, and 9.99 and less is actual. And so guaranteeing the lowest possible frame rate? Sounds like a truly bad idea. The whole thing has been discussed before. (Threads "Flying over an island" and "Estimating visibility"). Thomas FOERSTER announced that he'd use some Bayesian analysis to get a formula from various available parameters, such as temperatures, air pressure etc. http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15710.html http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15843.html http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15851.html In any case, if someone writes a heuristic, then this does *not* belong into SGMetar but FGMetar. Unless the weather subsystem is the next which is going to be ruined ... m. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: source/src/Scripting NasalSys.cxx, 1.128, 1.129
* James Turner -- Saturday 19 December 2009: > Onwards and upwards (in CVS, now). Shortest code review I've ever had (so > far!) Well, since people have taken over who pretend to know better (and I don't mean you), I can't be bothered to write verbose reports. :-P m. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: source/src/Scripting NasalSys.cxx, 1.129, 1.130
* James Turner -- Saturday 19 December 2009:
> - HASHSET("ils-frequency-mhz", 3, naNum(rwy->ILS()->get_freq() /
> 100.0));
> + HASHSET("ils-frequency-mhz", 17, naNum(rwy->ILS()->get_freq() /
> 100.0));
Still wrong. Since when do we use minus signs in variable names?
m.
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: source/src/Scripting NasalSys.cxx, 1.128, 1.129
* James Turner -- Saturday 19 December 2009:
> + HASHSET("ils-frequency-mhz", 3, naNum(rwy->ILS()->get_freq() /
> 100.0));
FAIL
m.
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flight Gear on Windows
* jean pellotier -- Friday 11 December 2009: > got something like that too on linux, but guess what? with an ati card I'm better off on Linux (with an nvidia card). I can at least decide whether I want clouds *or* material animations broken: http://members.aon.at/mfranz/material-shaders.jpg [54.9 kB] m. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Clouds
* syd adams -- Thursday 12 November 2009: > it would be nice to add hud #1 checkbox with a trailing 3D checkbox, hud #2 The two HUD implementations weren't meant to coexist so long. The removal of the old HUD and conversion of all aircraft to the newer one is overdue. I only had to implement the last missing features in the new one, and the old would have been history. m. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tone and decorum
* John Denker -- Thursday 05 November 2009:
> By way of pathetic non-excuse, let me remark that a few
> years ago I was rather authoritatively flamed for daring
> to put comments in FGFS code.
That's rather misleading. In fact you were criticized for:
- putting whole gdb stack traces(!) before several functions in a file
- "outdenting" comments within functions, thus making it harder to
see the code's logical structure
- adding needlessly verbose comments, while one the other hand ...
- using bad variable names in the code, like nnn, ttt, iii in just a
few lines of code. Here's an example from your patch:
+ nnn = props.globals.getNode("/sim/presets/" ~ varname, 1);
+ ttt = nnn.getType();
+ value = nnn.getValue();
Could have been "node" and "type". Or just "n" and "t".
But long *and* meaningless seemed like a bad combination. You
were invited to resubmit your patch with the points fixed, and
you chose not to. That's all.
m.
PS: beware: I can back that up with links to the archive!
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view manager "look at" mode
* Curtis Olson -- Thursday 23 July 2009: > The capabilities and reconfigurability of FlightGear is amazing. ... and have just (needlessly) been damaged by the vector property abomination. Now we get properties that are no longer accessible in all the traditional ways. And that required lots of code and is slower than alternatives. Sigh. m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] best way to remotely control flight gear?
* Eli Jordan -- Tuesday 14 July 2009: > as far as I could see the route manager only allows for pre set waypoints, > such as airports, i was hoping to be able to input co-ordinates (latitude > and longitude) and have the auto pilot fly between these. In telnet just type set /autopilot/route-manager/input -123.456,37.89 to append this waypoint to the list at runtime. That's ,. (Maybe we should swap those?) You can also demand a particular altitude: set /autopilot/route-manager/input -123.456,37...@8000 Possible formats are: (airport|fix|nav|lon,lat)[...@alt] -- e.g. "k...@900" There are commands available for clearing the list, removing entries, etc. @clear ... clear route @pop ... remove first entry @delete3 ... delete 4th entry @insert2:k...@900 ... insert "k...@900" as 3rd entry k...@900 ... append "k...@900" For example set /autopilot/route-manager/input @clear This works also from the property browser, or via Nasal etc. The route manager dialog uses the same interface. Of course, you have to use an autopilot which takes the waypoints from the route manager if you want your aircraft flown through all the points. The default AP does this. m. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: source/src/Scripting NasalSys.cxx, 1.124, 1.125
* Mathias Froehlich -- Sunday 07 June 2009: > Modified Files: > NasalSys.cxx > Log Message: > No need to zero the _props variable. > This reference is released by the SGSharedPtr destructor anyway. > > Modified Files: > src/Scripting/NasalSys.cxx > -_props = 0; Yes, but it's released when the SGPropertyNode_ptr is destructed, which happens in the ~FGNasalModelData() destructor, and that can be hours later. By setting it to 0 already here, we could save the memory for a potentially large animation property tree (as soon as cmdarg() released its reference as well). Do I miss something? m. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] Dynamic plug-in interface for I/O modules
I'm (still) against binary runtime modules for FlightGear. They are an invitation for circumventing the GPL, locking in users, and potentially harm cross-platformness. I find the prospect of a vendor offering a new device with closed source libraries for stock FlightGear worrying, and even more so if there's only a Windows DLL, but none for OSX and all the Unices/Linux. (Not that I'd want to run any secret binary blobs on my clean machine.) We offer more possibilities than X-plane and MSFS and all the others put together -- by letting people look at/modify/redistribute our source code. For free. That's very generous, if you ask me. That linking non-GPL modules would be illegal, anyway, doesn't make the situation any better. Unless you can offer us a *lot* of money, time and personnel for filing lawsuits. Otherwise the GPL protection is rather weak and only theoretical. We shouldn't encourage corporate entities to rip us off. m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] startup.nas
* Detlef Faber -- 6/23/2009 9:17 PM: > Am Dienstag, den 23.06.2009, 14:25 +0200 schrieb Melchior FRANZ: > > is now broken since Detlefs recent changes. > > I'm innocent on this. You sure meant someone else ;-) Whoops, indeed, sorry. (That was probably because Torsten and Detlef are both German first names which aren't used in Austria. :-) m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] startup.nas
* Tatsuhiro Nishioka -- 6/23/2009 5:01 AM: > I'm not so sure what it should look like, but at least it needs > nil check for the property. That would only be cosmetics and just hide the fact that the METAR runway choosing code is now broken since Detlefs recent changes. The METAR wind direction/strength is now published too late for startup.nas, so an aircraft isn't positionend on a proper runway if METAR is used. *This* is the problem that needs to be fixed, not the Nasal error message. startup.nas is/was a bit hackish, anyway. A proper solution would be to wait for the METAR wind and only then to set the runway and FDM. This would require to initialize the environment subsystem earlier. Then we could also drop the additional "presets-commit" and save some startup time. startup.nas could be dropped altogether. m. -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Gui - updating gui state dynamically
* James Turner -- 6/12/2009 11:05 AM: > I guess there is no chance of switching to osgWidgets in the near > future? I've not looked at how mature that code is or isn't yet. No. This may take another year, or two. AFAIK, osgWidgets is still nothing more than colored, clickable rectangles with labels and input fields -- basic building blocks for a GUI. But there's nothing like a scrollable list, comboboxes, 3D-widget effects, etc. Looks like we'd have to take over osgWidgets development to get it into a usable state. Switching now would be a big step backwards, and I see no reason for that. PLIB's pui works reasonably well, and it's not like it'll suddenly stop working. We can still put it in our CVS if we want to get rid of the PLIB dependency already. But there are still other things that we depend on, anyway (js handling, networking). m. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Gui - updating gui state dynamically
* James Turner -- 6/8/2009 10:56 AM: > Another, related question: is it possible to hide and show UI > element / groups dynamically? You can manipulate (add/remove/change) anything in a dialog before it's opened by embedded Nasal. You could have an XML dialog file with only a block, and let that create the whole dialog. At the moment you'd have to close and re-open the dialog to add widgets, though. > I checked over the dialog code, and I don't see a standard 'visible' > or 'hidden' property (looking at FGDialog::makeObject), but perhaps > there is some other way to achieve this? There's a property per widget group, which defaults to true. You can let the nasal part toggle that, in which case the widget won't be considered at all (including in the layouting). But toggling the property later won't have an effect. m. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Gui - updating gui state dynamically
* James Turner -- 6/8/2009 10:52 AM: > On 6 Jun 2009, at 08:46, Melchior FRANZ wrote: > I'll [...] try to keep PLIB'isms away as far as possible. Actually, I'll reorganize the code a bit so that possible later transitions to osgWidgets or other toolkits are even easier. And I intend to make all widget properties "live", so that one can, for instance, change the component (and optionally re-layout the dialog), and see the widget move. It'll be nice to have live color changes and to see the total weight text in the payload dialog turn red on overload etc. > I also hit problems trying to have PLIB notify the gui code > (and hence, Nasal script) when a text field lost focus - which > is a useful point to be able to 'commit' the contents and update > other UI state dynamically. Aren't s triggered then? Well, maybe not in all cases. I'll look into that. > One request, if possible, for the pop-up menus - it would be great to > be able to associate a hash with them, OK, sounds like a good idea. > Actually, if PLIB made it possible, the nicest thing would be a 'menu > about to open' script hook for the menus - which could then update the > contents directly. That's something available in many widget systems, > but again I suspect it might be tricky with PLIB. The trickiness isn't so much the problem. It's more the question how much time we still want to invest in PLIB. But I see no problems submitting necessary changes to PLIB. Actually, I've sort-of become PLIB's gui maintainer already, anyway. ;-) m. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Gui - updating gui state dynamically
* Melchior FRANZ -- Friday 05 June 2009: > With some code in dialog.cxx live updates of lists could be implemented, > too. Recent changes made that easier than before. This would really be the best approach. It could then also be used to live-enable/disable (grey out) widgets, or to change their color while the dialog is open, etc. I'll work on that in the near future and try to keep PLIB'isms away as far as possible. (Can't do it in the next few days, and I'd really also like to know first in which direction the property (mis)develops.) m. -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Gui - updating gui state dynamically
* James Turner -- Friday 05 June 2009:
> Can anyone (with more experience of the GUI code and Nasal) suggest
> how close I can get to a GUI like the one I've mocked-up below:
There are currently two ways:
- make the popup an extra dialog; See the dialog that's shown in "Model
View" in the lower left corner of the screen if you click on the model
name. It's defined in $FG_ROOT/gui/dialogs/model-view{,-select}.xml,
of which the latter is the popup.
- just fill the combobox s appropriately, and redraw the whole
dialog. That's problematic, though, if it interferes with user input,
because it happens while a user types into an input or something.
You have to read out the dialog x/y coordinations and to redraw the
dialog on the same place. The dialog dimension should better not
change in the new dialog.
With some code in dialog.cxx live updates of lists could be implemented,
too. Recent changes made that easier than before. I haven't done
anything of that sort yet, because we were discussing a switche from
plib to osgWidget, and more plib specific code didn't seem a good
thing at the moment, even though that switch isn't imminent.
I'd probably go with the first solution.
m.
--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Variable winds
* Torsten Dreyer -- Wednesday 03 June 2009: > You now have to fly your aircraft carefully, if you find something like > 28015G35KT 250V300 in your METAR. Arghh ... but seriously: sounds great! Thanks. :-) m. -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shift key ignored
* dave perry -- Friday 29 May 2009: > None of the keyboard inputs involving shift work any more. That's now fixed in OSG/SVN. m. -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shift key ignored
* dave perry -- Friday 29 May 2009: > I updated osg, SimGear, fgfs, and data from svn/cvs yesterday at > approximately 1400 zulu. None of the keyboard inputs involving shift > work any more. $ cd $OSG_SRC/src/osgViewer $ svn diff -r10268:10269|patch -p0 -R $ make && sudo make install m. -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Extending weather scenarios - Was: Visibility and ceiling options broken?
* Torsten Dreyer -- Sunday 24 May 2009: > Ideas and comments are welcome. If I play in someone elses sandbox here, > please complain! Sounds good to me. I did the METAR parser, Erik did the integration in fgfs, Harald did the scenarios. But this is not really someone's "sandbox", so go ahead! (I'd extend the parser if you run into problems or miss something.) m. -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terrain elevation under a solid AI aircraft
* Gijs de Rooy -- Wednesday 20 May 2009: > Melchior, you probably missed my last email. No, I haven't. But that was about bad aircraft placement by the AI subsystem and needs to be fixed there. Not exactly my domain, though I coud, of course, look into that. (I'm just not too keen to do boring stuff after the recent arguments. The project might still decide to go the wrong way, and then I'd feel sorry for every minute that I spent on it.) m. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terrain elevation under a solid AI aircraft
* Frederic Bouvier -- Wednesday 20 May 2009: > - "Melchior FRANZ" a écrit : > > Maybe use binary search for that. I take that back. Just take the prior intersection altitude, reduce it by a few centimeters and intersect again. There won't be that many layers. :-) > That would allow to place AI planes on the floor and not on the roof of the > jetways ;-) But I presume this is not done with Nasal. Not that I knew. But typically if there is an object at some coordinates, then you just don't want to put anything else excatly there, *on ground*. You either put it on top or a couple meters to the side. Let's wait until someone needs more, then we can still add the missing features. m. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terrain elevation under a solid AI aircraft
* Frederic Bouvier -- Wednesday 20 May 2009: > So if you really want to hit the floor and not the top of objects you can > iterate with different starting height until the second member is not nil ? Well, yes. Maybe use binary search for that. But that's still a waste of cycles if you really need the terrain altitude at some coordinates right away. I wouldn't oppose to an implementation for that, but I wonder if/when you actually ever need that. To measure an object altitude? What would be nice is an interface for intersections along a given vector other than straight down. Then one could ask for visibility in a particular direction or open/closed doors etc. m. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terrain elevation under a solid AI aircraft
* Frederic Bouvier -- Tuesday 19 May 2009:
> Maybe we could distinguish terrain and models in the traversal mask ?
> For the moment, every solid models has the terrain bit. Then geo.elevation()
> could accept a parameter that tells if it search terrain or solid objects.
geo.elevation() is just a convenience wrapper for geodinfo(). And while
that can't be limited to search only for terrain *or* objects, it is already
possible to determine whether a returned elevation was that of an object
or of terrain. Just add this code somewhere:
var loop = func {
var ac = geo.aircraft_position();
debug.dump(geodinfo(ac.lat(), ac.lon(), ac.alt()));
settimer(loop, 1);
}
loop();
... then fly along with the UFO. You'll get one set of geod(etic)info(rmation)
at the UFO's coordinates per second. There are three different kinds of
responses:
1: nil
2: [0.5990206304960102, { load_resistance: 1e+30, friction_factor: 1, \
names: ['pa_dspl_thresh'], solid: 1, bumpiness: 0, rolling_friction:
0.02, \
light_coverage: 0 }]
3: [10.13547897298338, nil]
The first is with no terrain or object below, the second is with terain below,
and the third is with an object below (no terrain data!). So you can also easily
see if you are under something: just test from your current altitude and from
10 m altitude. If the former returns terrain and the latter an object, then
you are in/under something.
m.
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terrain elevation under a solid AI aircraft
* Detlef Faber -- Tuesday 19 May 2009: > This means while trying to pass beneath a bridge, geo.elevation returns > the heigth of thebridge which will obviously stop the walker from moving > ahead. But geo.elevation() has an optional third argument that defines from which altitude down the intersection test should be made. Default is 10 km, but you can start from, say, 1.5 m above the walker's altitude. If there's an intersection, then s/he can climb up, otherwise it's an obstacle. And that should also work in hangars or under bridges. m. PS: yes, I forgot to mention this little detail in the geo.nas header. ;-) -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Possible new XML reader code
* Curtis Olson -- Saturday 09 May 2009: > I'm less sure about those who seem to feel the need to lash out > at someone every time they speak. You mean, those calling others "jerks"? m. -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Possible new XML reader code
* Gene Buckle -- Saturday 09 May 2009: > At least give him credit for trying to participate instead > of refusing to help because things didn't go his way. LOL. Erik is a core developer since many years. I've sent hundreds of patches to him for review and committing (and he rightfully rejected some), until *he* asked Curt that I get write access on my own. There's really no need to "give him credit", because his name is all over the place and there's no doubt that he's one of the main contributors to this project (unlike you). He does neither need my "credits" nor my "help". We can skip that and go to technical matters. And that's what I was trying to do. I know about our current XML implementation/integration. It's from David MEGGINSON -- another main contributor -- and also an XML guru and the father of SAX. Which is why I'm quite hesitant about a replacement of which I don't know if it's really better. The current parser seems quite sophisticated and works well. m. PS: http://www.ohloh.net/p/flightgear/contributors?page=1 He's ehofman. I don't find you on the list. -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Possible new XML reader code
* Erik Hofman -- Saturday 09 May 2009: > The downside of this code is that it is not 100% validating (so > it might accept xml syntax errors where expat didn't) and it > doesn't support DTD's. Hmm ... so it's sloppier *and* slower, but *maybe* increases runtime performance? Any benchmarks for the latter? Does it offer the traditional SAX interface that's used at several places in fgfs? Looks like it doesn't support "encoding" (UTF-8, latin1, ...) which is used in several files, or does it? m. -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: data/Nasal pushback.nas, NONE, 1.1
* Torsten Dreyer -- Tuesday 05 May 2009: > [...] the truck (door) keeps moving until it reached its final > position. Probably because the underlying interpolate() function keeps > running until its finished. Yes. But you can immediately stop the movement on with the aircraft.door.stop() method. m. -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: data/Nasal pushback.nas, NONE, 1.1
* Torsten Dreyer -- Tuesday 05 May 2009: > I moved the initialization of the aircraft.door object into the > pushback.xml when the dialog is opened. I assumed that the function should also be accessible via other means than just the dialog (e.g. keyboard bindings). If not, then I absolutely agree with your change. That's the cleanest way. > Is it OK to create a new instance of aircraft.door every > time, the dialog is opened? Yes. (It's generally better to keep class instances, and not to create/destruct them all the time. But in the case of dialogs that's really not an issue, as those are opened very infrequently, so your code is just fine and what I would have written as well.) > Does the old instance gets cleaned up by the garbage collector > after the closure of the dialog or after reopening the dialog? Yes. All local variables in dialog embedded Nasal are put in a separate module, and this is destroyed on closing. The only two things that one has to care for are timer loops and listeners. These should be stopped/removed manually. m. -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: data/Nasal pushback.nas, NONE, 1.1
* Melchior FRANZ -- Monday 04 May 2009: > - it uses variable names: Which would be fine, of course. I meant: *bad* variable names ;-) m. -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: data/Nasal pushback.nas, NONE, 1.1
* Alexis Bory - xiii -- Monday 04 May 2009: > But I do not have the piece which is necessary for testing. I didn't test it either. It's just obviously wrong (and ugly :-). Wrong, because ... - it uses aircraft.door before that is guaranteed to exist - because it doesn't use "var" where it should, and thus potentially breaks other code or gets broken by other code Ugly because ... - of pointless use of a class. This class has only one member (apart from the equally pointless "exporter"), and that member is shared by all instances. So what is a constructor call really meant to do? Construct redundancy? :-} - it just copies from the doors.nas file that lingers around everywhere (and that's also ugly ;-) -- including the comments, no matter if they make sense or not. (What does this mean: "objects must be here, otherwise local to init()"?) - it uses variable names: What should one expect from calling function pushback.pushbacksystem.pushbackexport()?! Not exactly self-explaining, if you ask me. The quality of code dumped into aircraft dirs is secondary, but it's probably a good idea to keep common code clean. m. -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: data/Nasal pushback.nas, NONE, 1.1
* Alexis Bory -- Monday 04 May 2009: > Added Files: > pushback.nas This is not only verbose and ugly code, it will cause error messages and not work on some machines. Just saying ... m. :-} -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* Tim Moore -- Wednesday 08 April 2009: > Here's the theory: the values in question, such as material > colors [...] OK, so on the OSG side it will always be a function call. There can by no tying (no matter which property types). On the fgfs side you can tie to memory, I assume. (red/green/blue/alpha separately, without costing anything extra.) And you need to poll the values for atomic changes? Maybe you could use the READ flag for that? No need to do it manually, of course. All wrapped in functions. That's just checking if the parent () node is read-protected, and if not, use the values. Otherwise re-use the previous ones. A setter would just clear that bit before writing the values, and set it again afterwards. Done by a function, of course, not manually. Unless I missed something, which could well be. m. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* Tim Moore -- Wednesday 08 April 2009: > I'm trying to give your generic approach a chance. I think a system > where you have to explicitly trigger a listener is a poor substitute > for one where the listener is fired automatically. But you'd only have to do it manually from the property browser or from telnet. In almost all cases it would be done from C++ or Nasal via wrapper functions, so not exactly manual either. > And I do think > > .2.3.4 > > blows compared to > .2 .3 .4 > but perhaps that's just me. But that's again the XML representation argument. As I said before, while I'm not thrilled about it, it's not what worries me. You could have a custom XML reader read that into three separate properties without problems. Just look at YASim's XML reader or the AI code's. What I find bad is the aggregate property type. > Better not tell anyone about our secret correspondence on the issue. > Oh. Whoops. > Seriously, suggesting that individual conversation among colleagues and > friends is "secret" and suspect [...] It's just that Curt referred to what you told him in private conversation apparently as a base for his opinion about the matter. And I think that others could use that same information as well to form theirs. Unless there's stuff that only Curt should know about it, of course. ;-) m. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* Durk Talsma -- Wednesday 08 April 2009: > The actual drop in frame rate observed by adding lots of traffic lies > somewhere in the graphics code [...] > If you really think the traffic manager code is inefficient: Please > prove it [...] N! I don't think that, and I have no clue about that. Also, just dropping features will always speed up code, that's easy. As I said, that wasn't to criticize the AI code, but to put things into proportion. Disabling some features gives tow-digit framerate improvements, or almost doubling. Introducing vector properties, OTOH, will probably not even bring you what is now wasted with inefficient use of properties. (We use the sprintf() path creation method in doubly nested loops at FDM frequency, for example.) m. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* Melchior FRANZ -- Wednesday 08 April 2009:
> But have you noticed that many subsystems use the property system in
> the slowest possible way?
>
| double f = fgGetDouble("/some/longish/property/path");
No, wait! The slowest possible way is to build the property path
first with sprintf(), although the property could well be stored
away as node pointer, as it never changes.
And that's done a *lot*, too!
m.
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* Melchior FRANZ -- Wednesday 08 April 2009:
> var f = fgGetDouble("/some/longish/property/path");
Oops. Make that double f = ...
m.
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* Heiko Schulz -- Wednesday 08 April 2009: > I don't think that Tim has not enough expertise [...] No, of course he has that. And so has Mathias. > to see at the next morning that you slamed this proposal code > changes before Tim even announced his proposal and put in here > for discussion. Yes. I really care! :-P m. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* Durk Talsma -- Wednesday 08 April 2009:
> Just the fact that a few extensions of the existing property types
> can have a positive impact on rendering speed, [...]
I wonder if it's worth to add a lot of complexity for that, though.
Do you know what users are usually told to do to increase the frame
rate?
- turn off the traffic manager! (I'm sure you aren't just wasting
cycles there, and there just *is* a lot to do. That's not meant
as criticism!)
- turn off the replay system (which really is a hog)
- turn off 3D clouds and trees
That brings a lot of frames. Now, would we gain a lot by adding
vector property types? That's hard to say. Nobody knows, I assume.
But have you noticed that many subsystems use the property system in
the slowest possible way?
var f = fgGetDouble("/some/longish/property/path");
Every time the property is read, a hash value of the path is made,
and looked up in the node's hash table. OK, hashes are fast, but
that's no reason to waste cycles. (One vector property supporter
seems to prefer this slow method. ;-) Nobody seems to care about
that (apart from me), while ruining the property system to gain
some cycles seems perfectly acceptable.
Did you know that Nasal code in bindings is read in, parsed and
translated to the interal code, and then executed *every* *time*
the binding is called? Every time you move the js throttle? Andy
said that parsing is very fast. Nevertheless, I wrote a patch that
cached all Nasal bindings. I didn't commit it, because the improvement
wasn't that big and not worth the added complexity. (I saved the patch
away in my git repo, and maybe one day it might come in handy.)
There are definitely many parts of fgfs that could be made faster.
I wouldn't start with adding vector property types. I wouldn't even
if it didn't come with all the disadvantages!
m.
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
Nobody wants to see fgfs stagnate. But that doesn't justify every approach, no matter which bad side effects. There is an alternative solution with *no* bad side effects, but all the same possibilities. None of the vector-property supporters even bothered to explain why this generic approach wouldn't work or would be worse. Again: the whole discussion is not (or shouldn't be) about whether we want progress, whether we want shader effects, and whether they should be configurable via XML. The question is, if this *very* intrusive approach is the way to go. Some of the vector property supporters don't seem to know a lot about all the internals and haven't thought about the side effects. Some even need to have "secret" private discussions with Tim to form an opinion. Why can't we discuss openly?! m. Excercises of the day: How should a vector property type be displayed on the HUD? All values in one line, rather than one line per element? Or is this really the begin of a two-class property system, where some propertyes are just no longer meant for inspection and "public" use, but internal only? How do you imagine we would write a that checks for a color's alpha value? -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: [Flightgear-cvslogs] CVS: source/src/GUI property_list.cxx, 1.22, 1.23
* Ron Jensen -- Tuesday 07 April 2009: > And when the gentleman who has been responsible for > building and maintaining that complexity stands up and cries out: That wouldn't be me, though. That's mostly David MEGGINSON's work, with contributions by Erik, Fred, Csaba, Mathias and me (and probably a few others). But I'm pretty sure that David, the designer of the framework, would be *horrified* about the idea of aggregate property types! I'm tempted to ask him ... m. :-} -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* Tim Moore -- Tuesday 07 April 2009: > Melchior FRANZ wrote: > > How/where do we document that the heading is in degree, not radian? > > > > How/where do we document that a value is normalized (0-1), not an > > angle? > > > Beats me, but I'm not the one claiming that the property list format is > self-documenting. Well, it is. The answer to my two questions is: suffixes! We know heading is in degree, because its name is "heading-deg". We know a value is normalized, because its name is "position-norm". And we'd know that a branch is atomic, because its name could be "whatever-atomic" (or something shorter). But that's just optional. > Right, so it's (mostly) the Nasal programmer who would have to know the > suffix. No. Any human who gets in contact with the property. For example, someone browsing the tree in the browser dialog. Or someone using it in nasal, or writing it from an fgcommand binding. The property tree is just data storage for IPC purposes. Writing to most nodes doesn't have an effect *at all*, without giving you *any* hint about that. You don't get any feedback on writing. You just have to know if you can expect an effect or not. Only some properties are polled or have listener callback functions attached, or are tied to functions. And a suffix could tell you that writing to a child alone doesn't have an effect either (like for most other nodes), but that the whole branch is evaluated in an atomic way if you trigger the parent node. m. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* Tim Moore -- Tuesday 07 April 2009: > How / where do you document that a parent node requires this explicit > listener activation? How/where do we document that the heading is in degree, not radian? How/where do we document that a value is normalized (0-1), not an angle? Adding a suffix would be a possibility. After all, just like in the case of "-ft" or "-m" suffixes, it's only meant for the human user or coder, so that s/he knows how to handle the type. The code itself knows it, because it's written that way. The listener of the (or ) node knows it without looking at the node name. That's just business as usual, not a new challenge. m. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* Tim Moore -- Tuesday 07 April 2009: > Melchior FRANZ wrote: > > > > alpha > > bravo > > charly > > delta > >So why do you care if and are replaced by ' '? Well, so far the samples usually looked something like this: 0.2 0.4 0.1 0.5. Doesn't look *that* bad, indeed. But in reality floats don't usually have just one digit after the comma. What about this? 2345.1239878725027 235.237926028973 558.1283745628374 9.123242342346 There goes the nicety. As long as this is only an XML markup question, the disadvantages are: - higher failure probability - one has to know about the order and meaning of elements; they are not self-describing - it's a bastardized format: it's a custom format *within* XML - XML tools can only treat the entry as a whole, but not the elements. For example: a *.dtd file cannot validate the entries (http://en.wikipedia.org/wiki/Document_Type_Definition; not that I have any experience with that) - XML editors might not support such conglomerates (ok, weak argument ... who on earth uses an XML editor?! ;-) If you find "proper" s so disgusting, then you could just use the XML parser directly, like Durk did it for some airport data (parking/traffic), or yasim to read its config files. Just write a shader XML file reader. You don't need to read them into the tree, I guess. I think it would be a bad idea, but I could live with it. (I've multiple times complained about such custom (non-) files in fgfs, because they made it impossible to load the taxiing files into the tree, for manipulating or visualizing the route points. I spent several hours for writing Nasal's parsexml() built-in function and io.readxml/io.writexml, only to allow that!) But that's all just XML representation. As soon as this thing ends up being stored in the property tree as new vec4, color etc. nodes, the fun is over: foo = '2345.1239878725027 235.237926028973 558.1283745628374 9.123242342346' (vec4) background = '0.12332975 0.123784967 0.28375891205 0.127456582302' (color) Should we make the property browser full-screen, so that one can still handle the entries? But that's only the response to your question: | So why do you care if and are replaced by ' '? The other issues are much more problematic. See the other messages for that. m. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* Tim Moore -- Tuesday 07 April 2009: > Is it fair to say that you never wanted a discussion, but instead > wanted to assemble people to yell at me to not make this change? No, it's not fair! May I remind you that we've had this same discussion a few times(!) on IRC? You asked me what I think about additional property types, and I've always made it clear that I'd object to that and why. This does *not* come as a surprise. And you knew my arguments. Even back then you didn't counter any of them IIRC, but rather concentrated on the "wouldn't-it-be-nice?" aspect. I think I have the IRC backlog from then, so looking it up shouldn't be be a problem. m. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* Anders Gidenstam -- Tuesday 07 April 2009:
> Some additional thoughts on atomicity: we have several levels of "setting
> a bunch of values in one go" in FlightGear:
The whole discussion is still much too detached from any actual use case.
What aggregate data block would we repeatedly set/read under circumstances
where speed actually matters? The XML shader files are read just once
when the model is loaded, no?
What other cases are there where reading three individual properties
is a problem, but reading one vector property isn't? And you can
easily write a small helper function that does the reading, so it's
in no way more annoying.
Atomicity is almost never an issue. Data set in the tree doesn't magically
affect c/c++ code, anyway. This has to be coded, in one of three ways:
tying, polling, listening. (Neither of them is thread-safe, no matter
if vector types exist or not. So this is IMHO not a criterion for the
decision.)
But apart from that you can have atomicity already now, as I've said
earlier. What's more natural than a color node where you can access all
components individually (e.g. attach a GUI slider to the element):
0.1234
0.431
0.2341
1
... and when you are finished with manipulating the color, you
validate the color change by "updating" the node. After
all the node stands for color branch with its elements.
A listener on the node copies the *atomar* color to the
GUI/material, etc. This only looks tedious if you ignore that it
can all be hidden in a few simple helper functions, like fgSetColor().
It's not like vector data types wouldn't also require lots of new
functions to work.
This approach is logical, generic, and doesn't break anything. You
can use the same technique on a font/{name,size,slant} aggregate,
or even a nested one: font/{name,size,slant,color/{red,green,blue}}
You don't have to change a core library for applying the same
principle to other aggregate types. You can implement it in Nasal only,
or C++ only, or mixed.
Implementing a "color" or "vec3" property is only picking out very
special cases and pretending they are in some way generic, while
ignoring all the other possible aggregate types. This is needlessly
extending a very functional, generic system instead of just *using*
it.
m.
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* Vivian Meazza -- Tuesday 07 April 2009: > There is no doubt that the introduction of arrays in the Property > Tree has both advantages and disadvantages. Not least we should > ask ourselves, if they are such a good idea, why aren't they in > it already? We've had arrays since we have a property tree! Here's an array of strings: alpha bravo charly delta http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* Tatsuhiro Nishioka -- Tuesday 07 April 2009: > I hope many people understands what Melchior said on the property > system. They don't. They are already drooling over the awaited shader changes. They fell for the argument that this change is in any way required/desirable, and they give a damn about the cleanliness, universality and power of the architecture. Prettiness does now have top priority, while a strong foundation was moved down the list. This will bite you all in the butt later on, but you were warned! :-P > His "going home" thing didn't mean that he just wants to hide > away unless his opinion is accepted, but he wanted to say the proposed > vector format is that bad in terms of software architecture. My announcement to leave was in response to Curt's "green light" and vote, to his opinion that the arguments against the change weren't strong enough. Had I assumed that this isn't decided yet, then I would neither have made the announcement, nor given up. But actually, I'm convinced that this *is* decided. FlightGear's architecture will be sacrificed to Tim's dislike of the verbosity of XML (a format that was chosen on purpose). Tons of code will be added everywhere to make the change kind-of work out. You'll never see any advantages, but some things will stop working. But then again: what do I lose? I will continue using fgfs, and I will continue hacking my private copy of fgfs. I'll just not commit any code to FlightGearTNG. I'll just be one of the bo105 developers (together with Maik). It's not so much a sad time for me, but mainly for FlightGear. m. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* Gene Buckle -- Sunday 05 April 2009: > So essentially since you may not get your way, you're going > to take your ball and go home? You don't seem to understand this comparison. It's about taking something away so that others can't continue enjoying the game, only because one doesn't have his way. I am not taking anything with me. I'm just going home, because the others have changed the game from football to throwing in windows. And that's not what I want to take part in. All you need for that is a spine. Nothing evil. m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* Curtis Olson -- Sunday 05 April 2009: > Without seeing anything so far that I would consider a compelling > argument against, I vote for giving Tim the green light here. > Developer convenience has almost always been a good enough reason > in the past. OK. Unfortunately, this is a route that I can't go with the project. I better watch that from outside. I still claim ownership of the bo105 and will probably continue maintaining it after a longer pause (if I can keep my commit rights until then). All other areas that I maintained are free for adoption (gui, fg/nasal, new hud, voice, input). Good luck m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* Melchior FRANZ -- Saturday 04 April 2009:
> Of course, triggering the parent
> would have to be done manually in the property browser or via
> telnet, but that's certainly not the main use case and is IMHO
> acceptable.
It's also easy to support from Nasal, in form of a new
props.Node method:
props.Node.setColorValues = func(r, g, b, a = 1) {
me.setValues({ r: r, g: g, b: b, a: a }); # set colors
me.setBoolValue(1); # trigger "valid"
}
Example:
props.globals.getNode("some/color", 1).setColorValues(1, 0.5, 0);
That's not the fastest way to write it, but good for showing
off. ;-)
m.
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
* Heiko Schulz -- Saturday 04 April 2009:
> How would it be better, and would all what Tim wants to do,
> be still possible?
The features that Tim is talking about (effects and stuff), and
the XML and property tree representation do IMHO not have much
to do with each other.
How can separate values be stored without vector property type:
Just like now. Every "property" (red/green/...) is a an actual
*property* (i.e. an SGPropertyNode). But we had that aleady ...
What the best solution for the "dynamic" attribute is probably
depends on the case. How often do we expect such color properties
to change? Many of them in every frame? Or just a few every few
minutes?
One solution could be to have the properties just like now
(with children possibly tied to memory):
color/{red,green,blue,alpha}
Add a listener to the parent "color", and trigger it when all
color properties have been set, so that the code can update
whatever needs to be updated. The triggering happens with
SGPropertyNode::fireValueChanged(). This can be nicely done
with a few helper functions. Of course, triggering the parent
would have to be done manually in the property browser or via
telnet, but that's certainly not the main use case and is IMHO
acceptable.
No intrusive changes with multiple bad side effects needed.
m.
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
