Curtis Olson wrote:
On Fri, Mar 20, 2009 at 6:51 PM, Tim Moore timo...@redhat.com
mailto:timo...@redhat.com wrote:
Gene Buckle wrote:
What benefit does the compound property offer?
g.
More concise syntax for aggregate values like colors, rotations, etc.
Tim Moore wrote:
Erik Hofman wrote:
Allright but how would you acces /model/skin/color/red in the new case then?
What do you mean by access? In C++ or Nasal within fg, or in the XML parse
within
another app? Why would you want red without green and blue and maybe
alpha?
In the color
Tim Moore wrote:
property node aggregates and aggregate C++ types is not a real problem
coding-wise. I just don't like the current XML syntax.
If this is you main motivation I'm just plain against this.
But I have the feeling that you're gonna regret this comment.
Erik
* Curtis Olson -- Saturday 21 March 2009:
To me the idea of giving nasal efficient access to vec3 and vec4 types for
manipulating things like material properties, texture coordinates, lighting,
and positions seems like the strongest argument for this proposal.
And that's quite a weak reason!
* gerard robin -- Thursday 19 March 2009:
I can only answer that i never had any problem with the actual AI/MP radar,
it is very flexible , since the main required values x-shift, y-shift, in
addition to the other useful aircraft data ( range-nm, altitude, heading )
are there. These data
Hi Csaba,
Csaba Halász schrieb am 21.03.2009 02:48:
I also wonder if property change listeners should get an additional
argument, giving the index of the changed item. But of course the
change would need to be detected first, which basically means we can
not directly expose a writable vec3d/4d
On Friday 20 March 2009, Tim Moore wrote:
RFC: Vector Types in the Property System
Proposal: Allow vector types as properties in property list XML
files and as properties in the runtime property system.
[snip...]
Rationale: Without these types, the XML syntax is much more
verbose
Melchior FRANZ wrote:
* Tim Moore -- Saturday 21 March 2009:
Gene Buckle wrote:
What benefit does the compound property offer?
More concise syntax for aggregate values like colors, rotations, etc.
Doesn't sound like a valid reason to me:
SGVec3 vec = n-getVec3Value(/some/vector);
Erik Hofman wrote:
Tim Moore wrote:
Erik Hofman wrote:
Allright but how would you acces /model/skin/color/red in the new case then?
What do you mean by access? In C++ or Nasal within fg, or in the XML parse
within
another app? Why would you want red without green and blue and maybe
alpha?
Erik Hofman wrote:
Tim Moore wrote:
property node aggregates and aggregate C++ types is not a real problem
coding-wise. I just don't like the current XML syntax.
If this is you main motivation I'm just plain against this.
But I have the feeling that you're gonna regret this comment.
Melchior FRANZ wrote:
* Curtis Olson -- Saturday 21 March 2009:
To me the idea of giving nasal efficient access to vec3 and vec4 types for
manipulating things like material properties, texture coordinates, lighting,
and positions seems like the strongest argument for this proposal.
And
Melchior FRANZ wrote:
* Tim Moore -- Saturday 21 March 2009:
Gene Buckle wrote:
What benefit does the compound property offer?
More concise syntax for aggregate values like colors, rotations, etc.
Doesn't sound like a valid reason to me:
SGVec3 vec = n-getVec3Value(/some/vector);
LeeE wrote:
On Friday 20 March 2009, Tim Moore wrote:
RFC: Vector Types in the Property System
Proposal: Allow vector types as properties in property list XML
files and as properties in the runtime property system.
[snip...]
Rationale: Without these types, the XML syntax is much more
On Sat, Mar 21, 2009 at 12:06 PM, Tim Moore wrote:
Melchior FRANZ wrote:
* Tim Moore -- Saturday 21 March 2009:
Gene Buckle wrote:
What benefit does the compound property offer?
More concise syntax for aggregate values like colors, rotations, etc.
Doesn't sound like a valid reason
On Fri, 2009-03-20 at 10:17 -0700, cullam Bruce-Lockhart wrote:
I just wanted to check on this before I muck it up, now that I finally
seem to have terragear compiled. I've got a couple of 1201X1201 grid
cells of raster data, covering a total of 0.5 deg X 0.5 deg. The
extension on the files is
Curtis Olson wrote:
On Sat, Mar 21, 2009 at 12:06 PM, Tim Moore wrote:
Melchior FRANZ wrote:
Doesn't sound like a valid reason to me:
SGVec3 vec = n-getVec3Value(/some/vector);
The syntax is actually:
Vec3d vec = n-getValueVec3d()
vs.
On Saturday 21 March 2009, Tim Moore wrote:
LeeE wrote:
On Friday 20 March 2009, Tim Moore wrote:
RFC: Vector Types in the Property System
Proposal: Allow vector types as properties in property list
XML files and as properties in the runtime property system.
[snip...]
Rationale:
Hello, Mathias
With JSBsim aircraft i get now some strange behaviour regarding the
groundcache on a moving Carrier.
We can start from catapult on carrier, and the Aircraft is sitting correctly
in place on the Ship , it follows correctly the speed of the carrier. = No
problem :)
After
18 matches
Mail list logo
