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 im
* 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 f
* 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
* 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 chang
* 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.
"user
* 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
"userarch
* Torsten Dreyer -- Wednesday 21 September 2011:
>
>
>
* 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: " << request
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
* 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
* 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
> lis
* 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/si
* 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 com
* 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
i
* 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 fi
* 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
* 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
st
* 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/bu0
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(
* 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
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
* "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
* "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.
---
* 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 we
--
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 bottleneck
* 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-us
* 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
* 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
* 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 mar
* 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
bo1
* 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.
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.
---
* 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
* 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/svgins
* 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 cha
* 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/sv
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 p
* 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
* 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
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 r
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/
* 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 s
* 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 D
* 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 - provide
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 visibi
* 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. (Thr
* 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.
--
* 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.
--
* 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 advan
* 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
* 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
* 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 se
* 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 cod
* 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-man
* 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 r
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
* 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
De
* 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/st
* 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 lab
* 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 tha
* 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
* 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
* 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 low
* 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.
--
OpenS
* 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 deplo
* 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.
* 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'
* 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 stu
* 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. :-)
* 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
* 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 c
* 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 inters
* 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 Scanne
* 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 som
* 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
* 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
* 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
* 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
* 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
* 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 & Sav
* 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/
* 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
* 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
* 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
* 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
* 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.
Y
* 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
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
* 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
* 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
* 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
* 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 lik
* 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
abou
* 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 u
* 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
* 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 a
* 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 w
* 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
* 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
* 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 val
1 - 100 of 1910 matches
Mail list logo
