Re: [Flightgear-devel] ..another nice promising bird in git: se5 :o)

[Vivian Meazza]

Arnt Karlsen wrote


> Hi,
> 
> ..it's a sweet wee pussycat as far as handling goes, also on roll-out,
> where it appears to _try_ carry the full weight of its shadow: ;o)
> https://github.com/gasguru/flightgearthings/raw/master/smoke-sheen/fgfs-
> screen-001.png
> 
> ..the sim brakes are ok in KSFO grass, but could use a disk lube job
> after brake disk rust removal, waaay too touchy now for KFSO tarmac.
> 
> ..pay due attention to the ground crew on start-up. ;o)
> 

Brakes on an SE5? There should be no brakes on an SE5.

Vivian



--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Logos and licensing

[Vivian Meazza]

Heiko

> 
> Hi,
> 
> 
> > * 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.
> 
> 
> I thought about that, but hoped no one will raise this up
> The question is still: how to proceed?
> 
> One of my liveries uses like Jack a copyrighted logo (taken from an own
> phto) and may not be used without permission.
> -->
> http://www.adac.de/impressum/default.aspx?ComponentId=6019&SourcePageId=67
> 29#ank6019-5
> 
> On the other side: there are many hundreds liveries with this Logo out
> there available.
> 
> Feeling a bit helpless
> 
> 

As Melchior said - or nearly said - "let sleeping dogs lie."

Vivian



--
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

[Vivian Meazza]

Erik wrote

> -Original Message-
> From: Erik Hofman [mailto:e...@ehofman.com]
> Sent: 27 February 2011 09:09
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Logos and licensing
> 
> On Sun, 2011-02-27 at 01:57 -0500, Chris O'Neill wrote:
> > I'm no lawyer, and I'm certainly not up on the law around the world, but
> > there's a concept in North American common law that one must take
> > "reasonable and prudent" steps to avoid liability.  With this concept in
> > mind, I respectfully ask whether it is "reasonable and prudent" to
> > explicitly take the position that we'll "look the other way" when a
> > possible copyright infringements are occurring?  Likewise, is the "if we
> > don't ask permission they can't say no" position reasonable and prudent?
> 
> To be honest I don't see any legal difference between creating an
> accurate livery for a virtual aircraft or publishing a photograph of the
> real aircraft.
> 

Yes!! At last some common sense. And if you publish a photograph or other
artwork YOU own the copyright.

We are not "using a trade mark". But if we ask a company to do so they bound
to say no, or they run the risk of losing their rights to their trade mark.

So we don't need to ask, nor should we. We are not "looking the other way",
or infringing copyright etc. 

While we are on about it - FlightSim Pro, or whatever they call themselves
this week, aren't breaking any laws either - they do comply with the terms
of the license. It is a scam, yes, but caveat emptor ...

Vivian







--
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

[Vivian Meazza]

Alexis wrote

> -Original Message-
> From: Citronnier - Alexis Bory [mailto:alexis.b...@gmail.com]
> Sent: 27 February 2011 14:01
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Logos and licensing
> 
> syd adams a écrit :
> > Just a thought , but maybe asking nicely rather than demands and
> > threats might work better ;)
> >
> > On Sat, Feb 26, 2011 at 11:32 AM, Jack Mermod 
> wrote:
> >
> >> I'm planning on contacting Red Bull today. If I get the green light, I
> >> better see my livery in the database lickity split!
> >>
> >>
> For those who don't read the forum:
> 
> http://www.flightgear.org/forums/viewtopic.php?f=4&t=10130&p=116069#p11606
> 3
> 

Exactly the answer to be expected. Note the "association" concept. Shouldn't
have asked.

Vivian



--
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

[Vivian Meazza]

John Holden wrote

> 
> This is the code section I've found so far, 1114(1)(a) is the most
> relevant:
> http://www.law.cornell.edu/uscode/html/uscode15/usc_sec_15_1114
> 000-.html
> 
> I don't know much about this but it does appear the confusion, mistake, or
> deception part at the end is the important part. I'll have to do more
> reading but that is why I proposed a disclaimer saying we are not
> affiliated or endorsed by anyone. I'll do some more reading later today to
> make sure this is correct.
> 

Glad you found that. Looks like we really have shot ourselves in both feet
by asking Red Bull. On the other hand - they might be overstepping their
rights at least in U.S (and I think U.K law). 

Since our use is NOT "likely to cause confusion, or to cause mistake, or to
deceive" there was never any need to seek anyone's permission. Red Bull is a
fizzy drink of some kind. FlightGear is not. Simples.

Vivian



--
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] c172j

[Vivian Meazza]

Syd

> 
> Hi guys ,
>  I modelled a c172j , the aircraft i trained in , and got the fdm
> working pretty accurately (except for slipstream effect) , but noticed
> that the yasim piston engine burned about 11 gallons per hour , about
> 3 gallons an hour more than the real one does full rich.
> Would it be possible for someone to make that an option in the config
> file similar to tsfc ? Or is that changeable and I just never found it
> ? My own yasim patches never made it further than this mailing list
> (not surprising considering my coding skill), but it would be nice to
> tune this parameter.
> Thanks,
> Syd
> 

I expect Andy will jump in here, but the fuel flow in Yasim can be modulated
by the use of the Mixture setting. If you want lower fuel consumption try
reducing the max mixture setting like this:



Perhaps Andy knows a better way, but that should work pro tem.

Vivian



--
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] c172j

[Vivian Meazza]

Victhor

> 
> I thought there was a bsfc element for turbine-engine or piston-engine
> engines in yasim...
> > Thanks guys . I did think of limiting the mixture with src / dst ,but
> > thought the ability to fine tune the fuel burn would still be nice.
> >
> > On Mon, Feb 28, 2011 at 1:50 AM, Vivian Meazza
> >  wrote:
> > > Syd
> > >
> > >>
> > >> Hi guys ,
> > >>  I modelled a c172j , the aircraft i trained in , and got the fdm
> > >> working pretty accurately (except for slipstream effect) , but
> noticed
> > >> that the yasim piston engine burned about 11 gallons per hour , about
> > >> 3 gallons an hour more than the real one does full rich.
> > >> Would it be possible for someone to make that an option in the config
> > >> file similar to tsfc ? Or is that changeable and I just never found
> it
> > >> ? My own yasim patches never made it further than this mailing list
> > >> (not surprising considering my coding skill), but it would be nice to
> > >> tune this parameter.
> > >> Thanks,
> > >> Syd
> > >>
> > >
> > > I expect Andy will jump in here, but the fuel flow in Yasim can be
> modulated
> > > by the use of the Mixture setting. If you want lower fuel consumption
> try
> > > reducing the max mixture setting like this:
> > >
> > > > >src0="0"
> > >src1="1"
> > > dst0="1"
> > >dst1="0.7"
> > > control="MIXTURE"/>
> > >
> > > Perhaps Andy knows a better way, but that should work pro tem.
> > >
> > > Vivian
> > >

Glad to be proved wrong - could you provide a reference for that in piston
engines in Yasim?

AFAIKS we only have a set value in src\FDM\YASim\PistonEngine.cpp:

// Presume a BSFC (in lb/hour per HP) of 0.45.  In SI that becomes
// (2.2 lb/kg, 745.7 W/hp, 3600 sec/hour) 7.62e-08 kg/Ws.

Vivian



--
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] another fuel change...

[Vivian Meazza]

Syd,

> 
> Me again ...
> As Heiko mentioned , my S76C broke due to a fuel.nas change . If the
> change was mentioned here , I guess i missed it completely.
> After some experimentation, I finally got it running again ...it
> wouldn't start due to empty tanks , and trying to fill them with the
> dialog didn't work they would immediately snap back to 0.I removed
> my nasal fuel routine , and everything worked again ,except with no
> fuel consumption now... would I be correct in assuming that I only
> have to supply the amount of fuel consumed per frame and fuel.nas will
> manage the fuel flow ?

Fuel.nas hasn't been touched since 20/11/2008 AFAIKS. Perhaps the problem
lies elsewhere?



--
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

[Vivian Meazza]

Chris wrote:

..
> 
> In my personal opinion, knowingly allowing the use of trademarks in
> aircraft liveries without the permission of the trademark holder
> *damages* this Project's integrity.  However, if the consensus of the
> core development team is that this kind of hair splitting is acceptable
> I'll shut up because, after all, I'm just a lowly end-user who happens
> to read this mailing list.  Therefore, my personal legal and/or
> financial risk is fairly minimal.
> 

I'm going to set you all a simple multiple choice test - pay attention
because I'm only going to say this once:

1. I take a digital photograph of you. Who owns the copyright of the digital
images produced?

A. Me
B. You

2.  I take a digital photograph of you standing next to your car. Who owns
the copyright of the digital images produced?

A. Me
B. You
C. The motor manufacturer
 
3.  A professional photographer stands in my place and takes a digital
photograph of you standing next to your car. The images are almost
indistinguishable from mine. Who owns the copyright of the digital images
produced?

A. The professional photographer
B. Me
C. You
D. The motor manufacturer

5. I make a drawing on paper of you and your car from the same viewpoint.
Who owns the copyright of the images produced?

A. Me
B. The professional photographer 
C. You
D. The motor manufacturer

6. I make a drawing using Photoshop or similar of you and your car from the
same viewpoint. Who owns the copyright of the images produced?

A. Me
B. The professional photographer 
C. You
D. The motor manufacturer

7. Do I have to ask permission of the motor manufacturer, the professional
photographer, or you to make or to publish my work on the internet?

A. No
B. Yes

8. I got there first. Does the professional photographer have to ask my
permission, or the motor manufacturer or you to publish his work?

A. No
B. Yes

Right. Hands up anyone who answered anything but straight As. Oh dear - in
Germany apparently I must seek permission from the motor manufacturer. I
expect BMW are very busy handling all the requests. That's probably why they
can't fix mine ... but that's another saga.

Bear in mind that almost all cars have their logo prominently displayed
front and rear. Does that change your answers? Self-evidently the answer
must be no. Otherwise, any image containing any object owned or manufactured
by anyone in the last 50 years would breach someone's copyright or
trademark. Professional photographers and artists could not exist. The art
world, of which we "aircraft developers" form a small and esoteric part
could not exist. Try telling that to http://www.airliners.net/ or
http://www.simmerspaintshop.com/ 


Here's one I did earlier. Anyone want to sue me?

http://img571.imageshack.us/f/lotus7.jpg/


Last question. Does Flightgear operate under different rules or laws?
 
A. No
B. Yes
C. In Germany

Anyone still confused? 

Vivian



--
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

[Vivian Meazza]

Jon

> 
> > I'm going to set you all a simple multiple choice test - pay attention
> > because I'm only going to say this once:
> >
> > 7. Do I have to ask permission of the motor manufacturer, the
> > professional
> > photographer, or you to make or to publish my work on the internet?
> >
> > A. No
> > B. Yes
> >
> > 8. I got there first. Does the professional photographer have to ask my
> > permission, or the motor manufacturer or you to publish his work?
> >
> > A. No
> > B. Yes
> >
> > Right. Hands up anyone who answered anything but straight As. Oh dear -
> > in
> > Germany apparently I must seek permission from the motor manufacturer.
> > I
> > expect BMW are very busy handling all the requests. That's probably why
> > they
> > can't fix mine ... but that's another saga.
> 
> When photographing *people*, if you plan to publish *and profit from* your
> photographs, then you may need a model release form. I've been involved
> several times in group events where photographers would not profit from
> the
> photographs they took, but got people to sign release forms anyhow out of
> courtesy, at least (see, for instance,
> http://en.wikipedia.org/wiki/Model_release, which expresses the same
> sentiments I have seen at professional photographer periodical web sites).
> 
> This is interesting, but I don't know if it offers any assistance:
> http://en.wikipedia.org/wiki/Trademark.
> 

There is no equivalent requirement in UK law. It might be useful, or
courteous, but there is no legal requirement for a model release: 

http://en.wikipedia.org/wiki/Photography_and_the_law

In the UK there is almost no privacy law, and photography is virtually
unrestricted. It is clear, however, that the photographer holds the in
copyright almost all situations - there are some minor exceptions.

Vivian





--
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

[Vivian Meazza]

Oliver

 
> Vivian Meazza wrote:
> > I'm going to set you all a simple multiple choice test - pay attention
> > because I'm only going to say this once:
> 
> Viviane you are on the complete wrong track, sorry.
> Taking pictures is documenting existing items while creating or redrawing
> items is a creatie work replicating the original.
> 
> If you take pictures from a person you enter his privacy which can be
> enforced
> by civil law. See http://en.wikipedia.org/wiki/Personality_rights
> I believe this is also covered by chapter 8 of the european human rights
> convention:
> http://www.echr.coe.int/NR/rdonlyres/92DB8BAC-7D8D-4C28-
> B927-1C1360A17DC3/0/FICHES_Droit_%C3%A0_sa_propre_image_EN.pdf
> 
> In various countries the rights of such a picture are with the person on
> the
> picture. Court rulings however make here exceptions eg. when photographed
> in a
> crowd or rights are transfered by contract (eg. somebody is paid for being
> pictured).
> Further exceptions relate to persons of public interests like celebrities
> and
> politicians. However court rulings vary in this area but often tend
> towards
> the pictured person.

In the UK there is definitely no such restriction on photography in law and
as far as I can see no court rulings (yet). There is, as yet, no right to
privacy, and no right to prevent photography or publication, expect in a
fairly narrow set of circumstances to do with security and terrorism,
obscenity etc. There is some concern here that privacy laws will do nothing
but benefit corrupt or pompous politicians, and there are quite enough of
those already.
 
> 
> This has been said multiple times before: Photographing an item,
> trademarked
> or not, is not an infringement. It is a documentation. The only issue (not
> trademark related) would be if that picture was taken by bypassing
> measures
> which should prevent from being pictured (eg. the item is placed at non-
> public
> locations or explicit denial of photographing has been stated).
> The same applies if you do a drawing of the same scene.

This concept doesn't seem extant in UK law. 
 
> If you draw a picture of the trademark as the central part this is
> creative
> work in the sense of doing derivate work of the original. This is still
> free.
> However if you distribute this item there is an issue as distribution is
> prohibited by trademarking laws- it could be mistaken as originating from
> the
> trademark owner.
>

It might be in Germany, but in the UK you have to register your trademark in
one or more of 45 classes. If your business does not fall within the same
class as the trademark, then there can be no infringement. For example we
would be in Class 9, while fizzy drinks are in Class 32. We should be OK in
the UK for most trademarks on aircraft. I haven't checked them all but for
example British Airways has registered in 2 or 3, and not in Class 9 AFAIKS.

Except Red Bull - who have registered in all 45 in 2009. However, they would
need to show that they had traded in our class in the UK though, which they
might or might not be able to do (I'm not aware of any Red Bull trading in
any computer related activity in the UK but ...) AND they would need to show
that there was a likelihood of confusion in the mind of the public. In any
case, we are not using the Red Bull logo, or anything similar, as OUR
trademark or logo. After 5 years their trademark will lapse in all the
classes in which they haven't traded.

So in summary - you say there is a problem in Germany, I say that there
probably isn't one in the UK and the US looks as if it might lie somewhere
in between. 

Finally, FG doesn't actually trade the UK or Germany in that we don't offer
a product for sale in those countries - does that matter?   

So where does that leave us?

> Now what if you take a photograph and place it as a picture on a
> helicopter?
> Nice try. But invalid. If you make a texture from the photograph it is no
> longer documentation but a derivative work used for a different purpose
> than
> looking at it in a photo album. 

I think we are in much more trouble with copyright law though. This is an
issue which we have long since ignored for current or nearly current
liveries. I don't really want to open that box.

> You are trying to boil a complex issue down to simple answers. It is not
> that
> simple.

It had better get simple, if we are to understand the problem and possibly
do something about it.

Vivian (not Viviane) 










--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Logos and licensing

[Vivian Meazza]

Chris

> On Thu, 2011-03-03 at 09:43 +0000, Vivian Meazza wrote:
> > I'm going to set you all a simple multiple choice test - pay attention
> > because I'm only going to say this once:
> 
> Okay, now it's my turn.  Please answer the following:
> 
> 1.  Is there a difference between a trademark and a copyright?
> 
> A.  Yes
> B.  No
> C.  It doesn't matter because we should be able to ignore either of them
> and include well-known logos on aircraft liveries if we want.

A. There is a very great difference, at least in the UK. In turns out that
Trademark protection is really quite limited. For example, the Cessna
trademark (word and logo) is registered only in Class 12. We would be able
to use Cessna in Class 9. Just like Polo (a sweet) and Polo (a car). 

Copyright of the logo - different question. "Well known" or not doesn't
change the equation.

Interestingly, Red Bull was once refused an injunction in the US against a
fizzy drinks company marketing a drink called Bullshit.

http://www.lawdit.co.uk/reading_room/room/view_article.asp?name=../articles/
Red Bull Trade Mark is Bullshit.htm

Which made me smile (yes, I'm easily amused) and perhaps sums up Red Bull's
corporate behavior pretty well IMO.

> 2.  Another flight simulator (X-Plane, MSFS, whatever) includes
> trademarks in their liveries.  Therefore...
> 
> A.  It must be okay to do this because *they* do it.
> B.  Even if it's not okay, we can do it because *they* do it.
> C.  It really doesn't matter what they do.  What matters is what *we*
> do.

A and B. Precedent is important. If Company A does not pursue Company B for
unlicenced use of their trademark or copyright then it is reasonable to
assume:

a. Company A doesn't care about such unlicenced use, or indeed might
see it as free advertising
Or  b. Company B is not, in fact, infringing that trademark (see Cessna
above) 

If we are in exactly the same business or class as Company B and we are sure
that the use is in fact unlicensed, it is also reasonable to assume that we
will get the same treatment. 

> 3.  Scenario:  It's against the law to drive 60 mph (100 kph) in a 30
> mph (50 kph) zone.  I drive 60 mph in a 30 mph zone but I always:  (a)
> make sure there are no police around, and (b) don't ask the police if I
> can do this.  Which of the following statements is true?
> 
> A.  It's only wrong to drive 60 mph in a 30 mph zone if you hit
> something or run over somebody.
> B.  Because I didn't ask permission (and so I couldn't be told I
> couldn't do it) and because no police are around, it is now okay to
> drive 60 mph in a 30 mph zone.
> C.  No matter what, it's wrong to drive 60 mph in a 30 mph zone.

D. It is however tacitly accepted that it is OK to drive at an _indicted_ 79
mph on UK motorways (the unwritten 10% + 2 rule). Same as the answer above.

> 3.  Scenario:  The FlightGear Project decides they will only distribute
> aircraft with liveries containing trademark icons if the trademark owner
> grants permission.  This means there are very few liveries containing
> trademarks in the distribution package.  However, anyone wanting to have
> liveries with trademarks can easily obtain them by Googling "flightgear
> liveries" and then going to a multitude of independent sites that have
> livery repositories.  Which of the following statements is true?
> 
> A.  That will spell the end of the FlightGear Project
> B.  That would work
> 

So we would have to ask our users to add dodgy liveries to our AI aircraft?
If they are classed as "FlightGear Liveries", and we take no steps to object
to other websites use of our name/logo, could we not also be guilty of a
infringement of the law by association? I don't know, I haven't researched
it, but shoveling a problem around is not solving it.  It would certainly
lead to fragmentation of the project, but I think that's already happening
to a certain extent. Not really a good idea. 

Personally, I don't care if I never see another airliner in FG, but there
are others who do.

Hmm, all thought provoking, and stimulated more research,

Thanks, Chris

Vivian







--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Logos and licensing

[Vivian Meazza]

Jon,

MSF probably, X-Plane, possibly, I don't know.

As I research this matter further, I think we have gotten ourselves
unnecessarily wound up about trademarks. At least in UK law.

When a trademark is registered here in the UK, the company declares in which
business it trades within classes. For example, Red Bull declares all sorts
of things, but NOT computer games: 

http://www.ipo.gov.uk/ohim?ohimnum=E698506

This is the official UK government site, so I think we can take that as good
evidence. UK law conforms to European and International standards: the
classes are set by international agreement. I would expect US law to be very
similar. If we think of ourselves as a computer game, I don't think we are
liable to any action by Red Bull, or pretty much anyone else on _trademark_
grounds. If on the other hand we believe that we are a software flight
simulator, then we are getting closer to, for example, Boeing business
activities.  

Copyright, hmm ..., the laws on copyright are draconian. That's hornets nest
that I'm not going to poke with a stick.  

Vivian

  

> -Original Message-
> From: S. Berndt [mailto:jonsber...@comcast.net]
> Sent: 04 March 2011 12:29
> To: vivian.mea...@lineone.net; FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Logos and licensing
> 
> I suspect that msfs and xplane have licensing agreements with trademark
> holders. It would of course be good to know this!
> 
> Jon
> 
> 
> Sent from my Samsung Captivate(tm) on AT&T
> 
> Vivian Meazza  wrote:
> 
> >Chris
> >
> >> On Thu, 2011-03-03 at 09:43 +, Vivian Meazza wrote:
> >> > I'm going to set you all a simple multiple choice test - pay
> attention
> >> > because I'm only going to say this once:
> >>
> >> Okay, now it's my turn.  Please answer the following:
> >>
> >> 1.  Is there a difference between a trademark and a copyright?
> >>
> >> A.  Yes
> >> B.  No
> >> C.  It doesn't matter because we should be able to ignore either of
> them
> >> and include well-known logos on aircraft liveries if we want.
> >
> >A. There is a very great difference, at least in the UK. In turns out
> that
> >Trademark protection is really quite limited. For example, the Cessna
> >trademark (word and logo) is registered only in Class 12. We would be
> able
> >to use Cessna in Class 9. Just like Polo (a sweet) and Polo (a car).
> >
> >Copyright of the logo - different question. "Well known" or not doesn't
> >change the equation.
> >
> >Interestingly, Red Bull was once refused an injunction in the US against
> a
> >fizzy drinks company marketing a drink called Bullshit.
> >
> >http://www.lawdit.co.uk/reading_room/room/view_article.asp?name=../articl
> es/
> >Red Bull Trade Mark is Bullshit.htm
> >
> >Which made me smile (yes, I'm easily amused) and perhaps sums up Red
> Bull's
> >corporate behavior pretty well IMO.
> >
> >> 2.  Another flight simulator (X-Plane, MSFS, whatever) includes
> >> trademarks in their liveries.  Therefore...
> >>
> >> A.  It must be okay to do this because *they* do it.
> >> B.  Even if it's not okay, we can do it because *they* do it.
> >> C.  It really doesn't matter what they do.  What matters is what *we*
> >> do.
> >
> >A and B. Precedent is important. If Company A does not pursue Company B
> for
> >unlicenced use of their trademark or copyright then it is reasonable to
> >assume:
> >
> > a. Company A doesn't care about such unlicenced use, or indeed might
> >see it as free advertising
> >Or   b. Company B is not, in fact, infringing that trademark (see Cessna
> >above)
> >
> >If we are in exactly the same business or class as Company B and we are
> sure
> >that the use is in fact unlicensed, it is also reasonable to assume that
> we
> >will get the same treatment.
> >
> >> 3.  Scenario:  It's against the law to drive 60 mph (100 kph) in a 30
> >> mph (50 kph) zone.  I drive 60 mph in a 30 mph zone but I always:  (a)
> >> make sure there are no police around, and (b) don't ask the police if I
> >> can do this.  Which of the following statements is true?
> >>
> >> A.  It's only wrong to drive 60 mph in a 30 mph zone if you hit
> >> something or run over somebody.
> >> B.  Because I didn't ask permission (and so I couldn't be told I
> >> couldn't do it) and because no police are around, it is now okay to
> >> drive 60 mph in a 30 mph zo

Re: [Flightgear-devel] Logos and licensing

[Vivian Meazza]

Arnt

> On Fri, 4 Mar 2011 15:48:52 -, Vivian wrote in message
> <2E88AF8A470944229CC999467FDABD4D@MAIN>:
> 
> > Jon,
> >
> > MSF probably, X-Plane, possibly, I don't know.
> >
> > As I research this matter further, I think we have gotten ourselves
> > unnecessarily wound up about trademarks. At least in UK law.
> >
> > When a trademark is registered here in the UK, the company declares
> > in which business it trades within classes.
> 
> ..in some jurisdictions, trade marks need merely be established, to
> become enforceable.  In others, established trade marks needs to be
> registered before they become enforceable.  Can of worms indeed.

Not at all - that is commonplace. So what?

> > For example, Red Bull
> > declares all sorts of things, but NOT computer games:
> >
> > http://www.ipo.gov.uk/ohim?ohimnum=E698506
> 
> ..no? ;o)  The language below can all be construed as relevant to
> a "RB v FG" trademark on Red Bulls "computer game trademark",
> square bracket comment [samples] are mine:
> Class 09:Scientific, nautical, surveying, photographic,
> cinematographic, optical, weighing, measuring, signalling, checking
> (supervision), life-saving and teaching apparatus and instruments;
> electric apparatus and instruments (included in class 9); apparatus for
> recording, transmission or reproduction of sound or images; ... ;
> magnetic data carriers, in particular video tapes, recording discs;
> automatic vending machines and mechanisms for coin-operated apparatus;
>  ... ; coin-operated fruit machines and entertainment
> machines; amusement apparatus adapted for use with television receivers
> only; ... , calculating machines, data processing equipment
> and computers; machine readable data carriers of all types with programs
> installed;

We would come under Class 09 - Computer Software - which is not listed as a
trading activity by Red Bull.

> Class 28:Games and playthings; ... ; electric or electronic games,
> [..is FG a game?  Can FG be run on non-electric things?]
> including video games; ... ; practical jokes (novelties).
> [..pranks?  Or physical items to execute a prank?  Or, are
> they trying to trademark satirical etc jokes?  Etc.]

We are not a Game or Plaything, certainly NOT an "electronic game"
 
> Class 35:Advertising, in particular promotion of the aforesaid goods
> and of competitive events, including competitive events of a sporting
> nature; arranging of advertising; distribution of goods for advertising
> purposes; ...
> [..product "placement"?]

What has this got to do with us?

> Class 41:Education; providing of training; entertainment, in particular
> musical performances and radio and television entertainment; sporting
> and cultural activities, in particular the staging of sports
> competitions; organisation of exhibitions and trade fairs for cultural
> and educational purposes; rental of video tapes and cassettes, video
> tape film production.

We don't do education do we? 

> 
> Class 42:... ; scientific and industrial research; exploitation of
> industrial property rights; technical consultancy and providing of
> expertise; computer programming; ...

Class 42: Services - which you omitted to say - we don't offer any services.
 
> ..yes, it's overbroad, RB tries to trademark jokes on themselves, and
> yes, IBM is still waiting to clear its name slam dunk style, and case
> law will tell you guys, satire is our safest defense, despite all it's
> flaws, Red Bull is neither Microsoft nor tSCOG.

Do we need any such defense? There is no sensible overlap between our
business activities and those registered by Red Bull. But I chose that only
as an example. 

> > This is the official UK government site, so I think we can take that
> > as good evidence. UK law conforms to European and International
> > standards: the classes are set by international agreement. I would
> > expect US law to be very similar. If we think of ourselves as a
> > computer game, I don't think we are liable to any action by Red Bull,
> > or pretty much anyone else on _trademark_ grounds. If on the other
> > hand we believe that we are a software flight simulator, then we are
> > getting closer to, for example, Boeing business activities.
> >
> > Copyright, hmm ..., the laws on copyright are draconian.
> 
> ..yes, but more uniformly so, so they are easier to
> live with and to enforce on e.g. GPL violations.
> 
> > That's hornets nest that I'm not going to poke with a stick.
> >

> 
> ..neither is Microsoft ;o) ... except by tSCOG etc proxies...
> 

Well, that's good to know

Vivian



--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https

Re: [Flightgear-devel] Logos and licensing

[Vivian Meazza]

Syd wrote

 
> > But definitely: The designer should take the risk for it - and if too
> > young: The parents should support it - that is standard in any legal
> > business matter for youngsters!
> 
> I agree here ... being mainly a 'content creator' , I think I'm
> responsible for content I create , and
> dumping problems in the fg communities lap is not my intention.I've
> also noticed that most aircraft designer's already have their own
> webpages to distribute what is in the git repository already.Cleaning
> up the Aircraft directory could be a major task though , and I don't
> feel too concerned about the whole issue , but if it comes to it , I
> hope those with write access wont hesitate to remove any of my work.

If I might wrap this one up by summarizing my research and our interesting
and valuable discussion here:

1. Trademarks. We might or might not infringe a particular trademark
depending on the terms of the registration. I have given examples across the
spectrum. 

2. Copyright. I wasn't going to address this one on the assumption that we
aircraft developers, as copyright holders ourselves are well aware of the
law, but:

"Copyright is infringed where either the whole or a substantial part of a
work is used without permission, unless the copying falls within the scope
of one of the copyright exceptions."

The exceptions do not apply to us. Copyright does not have to be registered,
it exists if the work is original. 

3. Enforcement. In the event of an infringement, rights have to be enforced
by the trademark/copyright holder. In the first instance, this is most
likely to be an instruction to remove the offending item. If we comply that
is likely to be the end of it, but it is open to the rights holder to go to
court and seek damages. Some legislations (certainly the US and UK) have the
concept of "Fair Dealing",  There is no strict definition of what this means
but it has been interpreted by the courts on a number of occasions by
looking at the economic impact on the copyright owner of the use. Where the
economic impact is not significant, the use may count as fair dealing. 

4. Permission. A developer may seek permission from a rights holder. I would
assess that would be more likely to succeed if permission were sought under
copyright to reproduce the logo, rather than "use their trademark" since:

a. that describes most accurately what we do
and   b. trademarks are a valued resource and not lightly given away or
licensed. 

You could then put "reproduced with the kind permission of ... " on your
work. However, we have been informed very unofficially by one company that
if we do ask they will have to say no, but they are unlikely to enforce
their rights. If you ask, and get the answer no, then I think you are
duty-bound not to go ahead regardless.

5. Scope. This affects a relatively small number of items in our data,
principally, but not exclusively, the logos or trademarks of extant
airlines. 

6. Way Ahead. When I use the term "we" or "us" I really mean Curt, since it
his name which appears on our website. So over to you, Curt.

Enough already. I now know more than I wanted to about trademarks, but I
have enjoyed the intellectual exercise. Now what was that about FlightPro
Sim ...

Vivian  




 



--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Logos and licensing

[Vivian Meazza]

Heiko

> 
> > Or maybe Company A hasn't yet noticed that Company B is
> > using the
> > trademark without permission?
> 
> I doubt that!
> X-Plane is very well known already, much more than FlightGear. Austin has
> laywers, he certainly knows what he is allowed to do. (on the contrary to
> us! ;-))
> 
> >
> > LOL!  No fair adding answers!  ;)  Btw,
> > while 99.9% of the time the cops
> > will "look the other way" for speeding just slightly above
> > the posted
> > limit, it's *still* against the law and you *could* get
> > pulled over and
> > at least get a warning.  So, no, "unwritten rules"
> > don't change the law,
> > they just change how the law is enforced...  two
> > totally different
> > concepts.
> 
> What Vivian wants to say is, that there is certain degree of margin.
> Or do you want me to tell you are able drive exactly 55mph 100% exactly
> without tempomat anytime needed?
> 
> The fact is: there are some "Trademarks" which can be used without any
> problems. "Police", "Post" or "Red Cross" and a lot of others.
> I know one company which even put up a detailed set of their paint scheme
> including their Trademark for Download just for modelers.
> 
> 
> >
> > I don't accept that having an aircraft that doesn't include
> > a trademark
> > on the livery makes that aircraft (or livery)
> > "dodgy."  Personally, I
> > don't fly an aircraft because of the livery it has but,
> > rather, because
> > I like the way the aircraft flies.  I know there are
> > those who say that
> > the FG Project will be "ruined" if we don't include
> > trademarks in the
> > liveries, but personally I doubt that would be the case.
> 
> 
> If you would take a look into the forums of FlightGear, X-Plane, MSFS you
> would see that it is very popular to repaint aircrafts and that it is very
> attracting to fly their "own" aircraft.
> There is high number of payware addons companies who certainly don't pay
> any fee because they use any trademark for a livery.
> 
> 
> Ever heard of this sentence? "An aircraft which looks good and pleasant,
> also does fly like that"
> Of course mostly of their shape, but often the painting completes their
> well-designed shape.
> 
> We have people flying aircraft in FGFS due to their flight behavior.
> We have people flying aircraft in FGFS due to their nice modelling.
> We have poeple flying aircraft in FGFS due to both.
> 
> You have to acceppt that there are more people involved than just you.
> And yes, I fear also that we may loose attraction compared to other sims
> when we start to delete liveries with any trademark.
> 
> 
> > And, finally, if it's really the case that FG simply *must*
> > have symbols
> > on our aircraft liveries, what's wrong with *make believe*
> > icons?  Is it
> > *really* such a "disaster" if we don't have Red Bull,
> > Macdonalds,
> > Guinness, United Airlines, TWA, or any other trademarked
> > symbol on our
> > aircraft?  Frankly, i think not!
> 
> What's wrong with *make believe* icons? Depending on the owner of the real
> icon it can be that you still be sued for.
> There have been a lot of examples (especially Red Bull) like that. Juist
> google for "Blue Bull".
> 
> 
> The fact is- no one, not you, not me, not anybody here does really know
> what we may, and what not.
> 
> I discussed this issues with Oliver Off-list, and he pointed to me that we
> may have use in germany some trademarks just because they are part of the
> daily life. So it would be possible to use "Lufthansa" without any
> problems. And indeed: they just don't like VirtualAirlines with their
> name, but don't mind any repaint.
> And there are some examples more.
> 
> Trademarks not of the daily life (like Red Bull) can't be used that
> easily. If someone wants still to use it, he is in the risque to be sued.
> 
> 
> Of course, this is in germany- how it is in UK? or in australia? In
> russia?
> Even in each country the different courts may decide different on the same
> issue.
> 
> 
> I can can only follow John Holden's statement: we should make us aware of
> what we are allowed to and what not. What are our rights?
> 

Nice summary: I think you have answered your own question :-). Your rights?
You have copyright over anything that is your original work. Anything else,
someone else probably has a right over. If not trademark, then copyright.
They may chose not to exercise that right (yet), or give you permission.
There is some latitude: "Fair Dealing" (where that exists) and as you
mentioned above etc. Don't assume that because a trademark exists that it
can't be used in a different context. That depends on the Class(es) in which
it is registered.  That's probably it.  

I thought I would do a bit of research over at X-Plane. I see that they have
registered X-Plane as a trademark in the US - that would seem sensible. I
don't see any reference to other trademarks or copyrights. I half expected
to see something like "All logos and trademarks are reproduced with the kind
permission of their re

Re: [Flightgear-devel] Logos and licensing

[Vivian Meazza]

Oliver

> Vivian Meazza wrote:
> 
> > One final thought. We have been using logos in FG ever since I've been
> > involved - 2004 and probably longer. In that time we have not had a
> > problem. Are we saying that no rights holder has ever noticed it
> anywhere?
> > I find that a bit improbable; perhaps they aren't looking or aren't
> > bothered.  Of course, I'm inviting disaster to strike us Monday morning.
> 
> Ah, yes, at night, I am sneaking into my neighbors garden and take
> photographs
> of her in her bedroom through the window. I do this since 2004 and she has
> never complained. So I believe it is ok to go on with that as proprably
> she
> finds this acceptable.

Since she doesn't know about it she cannot have an opinion either way, but
since she leaves the curtains open she must accept the possibility of it
happening.

> 
> Now back to that damn guy who regularly puts his trash in my can. I'll hit
> him
> with a large stick.
> 

Good solution, if you can catch up with him. You would of course be guilty
of a serious crime.
 
> P.S.: Noted the sarkasm?

P.P.S. The sarcasm? Not really, I thought you were just using clever
metaphor.

Vivian






--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Using native OSG 3D models - is it possible?

[Vivian Meazza]

Stewart wrote

> -Original Message-
> From: S Andreason [mailto:sandrea...@gmail.com]
> Sent: 19 March 2011 15:35
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Using native OSG 3D models - is it
> possible?
> 
> Hal V. Engel wrote:
> >
> > The model I am looking at only has one mesh [...clip...] drapped over
> > a set of armatures (bones) [...clip...] AC3D has no support for
> > armatures as far as I can tell so this imformation is lost on export
> >
> 
> If it is only one mesh, then that says it all.
> 
> Correct. That technique is new, and not supported by AC3D.
> 
> 
> > Inside of Blender the posing process is actually very elegant
> >
> Yes, Blender is more advanced, and I would say since aircraft are not
> organic and flex thus, it has not been a priority for the fg developers
> to focus in this direction. Only Detlef and myself have put effort into
> getting any body animations, from which other piloted aircraft and
> carriers have benefited. (Correct me if I'm missing something, Vivian)
> 
> > The walker model is much like the existing modern pilot that is part
> > of the P-51D.
> I forget which pilot was version 1, but the current walker came about
> after Detlef and I improved the pilot.
> 
> > Very unnatural and complex to animate and with seams at the joints
> > that are visible.
> I know, it is looking old already, but it is better than nothing.
> I hope someone else will feel inspired, and be talented enough to pick
> up where I left off.
> 

Not quite - I animated the pilot in the Hunter and Seahawk way ahead of
that. I have a crudely jointed model. But it just takes too long to adjust,
and I was hoping that we might do it in a more professional manner.

We nearly got there under PLIB, but there were some fundamental bugs we
couldn't overcome. That thread of development just got lost in the cut over
to OSG. I think there is something built-in to OSG, but we never got around
to porting it to FG. Along with all the other things we didn't do with OSG. 

Google Summer of Code might have addressed one or more of these things, but
I think the deadline was missed again this year. 

Vivian



--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Using native OSG 3D models - is it possible?

[Vivian Meazza]

Hal,

 

Good to hear, well done. I hope and expect that it all works out for you.

 

We never even got close to trying AFAIKS.

 

Vivian

 

-Original Message-
From: Hal V. Engel [mailto:hven...@gmail.com] 
Sent: 19 March 2011 19:20
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] Using native OSG 3D models - is it possible?

 

On Saturday, March 19, 2011 09:53:52 AM Vivian Meazza wrote:

> Stewart wrote

> 

> > -Original Message-

> > From: S Andreason [mailto:sandrea...@gmail.com]

> > Sent: 19 March 2011 15:35

> > To: FlightGear developers discussions

> > Subject: Re: [Flightgear-devel] Using native OSG 3D models - is it

> > possible?

> > 

> > Hal V. Engel wrote:

> > > The model I am looking at only has one mesh [...clip...] drapped over

> > > a set of armatures (bones) [...clip...] AC3D has no support for

> > > armatures as far as I can tell so this imformation is lost on export

> > 

> > If it is only one mesh, then that says it all.

> > 

> > Correct. That technique is new, and not supported by AC3D.

> > 

> > > Inside of Blender the posing process is actually very elegant

> > 

> > Yes, Blender is more advanced, and I would say since aircraft are not

> > organic and flex thus, it has not been a priority for the fg developers

> > to focus in this direction. Only Detlef and myself have put effort into

> > getting any body animations, from which other piloted aircraft and

> > carriers have benefited. (Correct me if I'm missing something, Vivian)

> > 

> > > The walker model is much like the existing modern pilot that is part

> > > of the P-51D.

> > 

> > I forget which pilot was version 1, but the current walker came about

> > after Detlef and I improved the pilot.

> > 

> > > Very unnatural and complex to animate and with seams at the joints

> > > that are visible.

> > 

> > I know, it is looking old already, but it is better than nothing.

> > I hope someone else will feel inspired, and be talented enough to pick

> > up where I left off.

> 

> Not quite - I animated the pilot in the Hunter and Seahawk way ahead of

> that. I have a crudely jointed model. But it just takes too long to
adjust,

> and I was hoping that we might do it in a more professional manner.

> 

> We nearly got there under PLIB, but there were some fundamental bugs we

> couldn't overcome. That thread of development just got lost in the cut
over

> to OSG. I think there is something built-in to OSG, but we never got
around

> to porting it to FG. Along with all the other things we didn't do with
OSG.

> 

> Google Summer of Code might have addressed one or more of these things,
but

> I think the deadline was missed again this year.

> 

> Vivian

 

GSoC sent out acceptance/rejection letters to mentoring orgs yesterday. I am
one of the Admins for an orginization that got accepted so I will be doing
GSoC paper work this week end. It takes a lot of prep work to get things
ready for GSoC so it is easy to not get things ready in time. But it would
have been great if FG had been able to leverage GSoC to get some specific
things done.

 

Hal

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FlightGear at LinuxTag and FSWeekend needyour

[Vivian Meazza]

Martin wrote


> 
> Torsten Dreyer wrote:
> 
> > As many of you might be aware of, a group of FlightGear enthusiasts have
> been
> > presenting FlightGear at FSWeekend in Lelystad(NL) and LinuxTag in
> Berlin(DE)
> > over the last years.
> 
> I just recieved confirmation:
> 
> "we are excited to inform you, that your application for the project
>   FlightGear Flight Simulator
> qualified for a sponsored booth at this year's LinuxTag."
> 

Very good. I hope we will have something new to show - like a new release. 

What happened to that?

Vivian





--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Adventures in dds

[Vivian Meazza]

Heiko wrote,

> 
> 
> >
> > I don't know what that has to do with xml - it seems
> > generic that if I
> > increase the number of objects to render, the framerate
> > drops. I can see
> > the same thing with trees (which to my knowledge are not
> > xml-wrapped
> > models) - if I increase tree density by a factor 10, I see
> > my framerate
> > drop like a rock. 5000 additional models in the scenery
> > will affect
> > framerate, quite possibly inversely proportional to their
> > texture quality
> > and proportional to the operations required by the relevant
> > shader -
> > regardless if that's houses or clouds.
> 
> 
> With 1.9.1 there wasn't a big difference between placing pure .ac-models
> and .xml-wrapped models into scenery. Both had the same fps.
> 
> Now it is different. The same number of .ac-models  will give higher fps
> than the same number of wrapped .xmls.
> >
> > The system (as far as my experience goes) isn't
> > particularly slow in
> > rendering the clouds once they are in the scene. It is slow
> > in placing
> > them into the scene - dramatically slower (a factor 1000 or
> > so) than with
> > the standard 3d clouds. If you want to call that 'wrong' is
> > in the eye of
> > the beholder - that's how the interface for model placement
> > from Nasal is
> > at present.
> 
> Hmm... I did not have found time for a detailed table of fps comparement,
> but it seems to me that some of your clouds are decreasing fps more than
> the default 3d-clouds. It looked different to me at the beginning, but
> making some videos showed me this.
> 
> >
> > That  slowdown for sure is generic for the way models
> > are placed from
> > Nasal - something appears to be *very* inefficient with
> > that. I am rather
> > skeptical if it's to be blamed on the xml wrapper - I see
> > no supporting
> > evidence. The dependence on texture type and detail level
> > suggests to me
> > that it's about uncompressing and loading textures into the
> > GPU memory.
> 
> If I'm right, .xmls and nasal are handeld by the CPU.
> The Default clouds are mostly done by the GPU.
> 

I still have some old textures in Git that I have not yet changed over to
.png. Do I take it from these discussions that it would be best to leave
them as is?

I'm right in the middle of texturing a new model. .dds is not an option
because it looks as if the loader has some co-ordinate issues. It looks OK
in AC3D, but when loaded in FG it's wrong. Should I revert to .rgb rather
than use .png?

Vivian



--
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] Adventures in dds

[Vivian Meazza]

Heiko,

> -Original Message-
> From: Schulz [mailto:aeitsch...@yahoo.de]
> Sent: 21 March 2011 20:35
> To: vivian.mea...@lineone.net; FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Adventures in dds
> 
> Vivian,
> >
> > I'm right in the middle of texturing a new model. .dds is
> > not an option
> > because it looks as if the loader has some co-ordinate
> > issues. It looks OK
> > in AC3D, but when loaded in FG it's wrong. Should I revert
> > to .rgb rather
> > than use .png?
> >
> > Vivian
> >
> You have to flip the .dds-texture vertically after converting to it.
> That's due to OpenGL.
> 

A simple vertical flip doesn't seem to work - it looks a bit more like a
scaling issue here.

Perhaps I need some tool?

Vivian



--
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] Adventures in dds

[Vivian Meazza]

Heiko,

> 
> Vivian,
> >
> > I'm right in the middle of texturing a new model. .dds is
> > not an option
> > because it looks as if the loader has some co-ordinate
> > issues. It looks OK
> > in AC3D, but when loaded in FG it's wrong. Should I revert
> > to .rgb rather
> > than use .png?
> >
> > Vivian
> >
> You have to flip the .dds-texture vertically after converting to it.
> That's due to OpenGL.
> 

Here's the AC3D version:

ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_AC3D.png


And here's what I see in FG:

ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_FlightGear.png

Vivian



--
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] Adventures in dds

[Vivian Meazza]

> -Original Message-
> From: Emilian Huminiuc [mailto:emili...@gmail.com]
> Sent: 21 March 2011 22:00
> To: vivian.mea...@lineone.net; FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Adventures in dds
> 
> On Monday 21 March 2011 23:47:51 Vivian Meazza wrote:
> > Here's the AC3D version:
> >
> > ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_AC3D.png
> >
> >
> > And here's what I see in FG:
> >
> >
> ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_FlightGear.png
> >
> > Vivian
> 
> That's exactly what me and Heiko were saying, you need to flip the texture
> vertically, BEFORE converting it to a .dds.

Heiko said this:

"You have to flip the .dds-texture vertically after converting to it"


So that what I did. Now I'll try it the other way.

Vivian



--
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] Adventures in dds

[Vivian Meazza]

I wrote: 
> > -Original Message-
> > From: Emilian Huminiuc [mailto:emili...@gmail.com]
> > Sent: 21 March 2011 22:00
> > To: vivian.mea...@lineone.net; FlightGear developers discussions
> > Subject: Re: [Flightgear-devel] Adventures in dds
> >
> > On Monday 21 March 2011 23:47:51 Vivian Meazza wrote:
> > > Here's the AC3D version:
> > >
> > > ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_AC3D.png
> > >
> > >
> > > And here's what I see in FG:
> > >
> > >
> >
> ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_FlightGear.png
> > >
> > > Vivian
> >
> > That's exactly what me and Heiko were saying, you need to flip the
> texture
> > vertically, BEFORE converting it to a .dds.
> 
> Heiko said this:
> 
> "You have to flip the .dds-texture vertically after converting to it"
> 
> 
> So that what I did. Now I'll try it the other way.
> 
Makes no difference flipping before conversion or after - Looks OK in AC3D,
but not in FG. So it doesn't look like .dds is a proper option without
further work.

Vivian



--
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] Adventures in dds

[Vivian Meazza]

Emilian,

> On Monday 21 March 2011 23:47:51 Vivian Meazza wrote:
> Vivian,
> > Here's the AC3D version:
> >
> > ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_AC3D.png
> >
> >
> > And here's what I see in FG:
> >
> >
> ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_FlightGear.png
> >
> > Vivian
> The workflow would be like this, you map the model onto a .png texture.
> You
> finish drawing the texture, and before loading it into flightgear these
> two
> steps should be the last ones:
> You flip that texture verticaly (in gimp for example), then you convert
> the
> flipped texture to .dds.
> 
OK, I'll try that

Vivian



--
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] Adventures in dds

[Vivian Meazza]

Heiko,

> -Original Message-
> From: Schulz [mailto:aeitsch...@yahoo.de]
> Sent: 21 March 2011 22:32
> To: vivian.mea...@lineone.net; FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Adventures in dds
> 
> Hi,
> 
> 
> > >
> > Makes no difference flipping before conversion or after -
> > Looks OK in AC3D,
> > but not in FG. So it doesn't look like .dds is a proper
> > option without
> > further work.
> >
> > Vivian
> >
> 
> You must doing something wrong.
> 
> here for Gimp, assumed that you have the plugin needed already:
> 
> 1.) UVmap the aircraft in ac3d as usual with your png-file
> 
> Then:
> 
> 1) Take the .png-file you want convert
> 2)Image --> Transformation -->Mirror (flip?)vertical
> 3)Save as "name.dds"
> 4.)a popup appears, select DXT5 and check "mipmap"
> 5) click o.k.
> 
> Open the .ac-file with a text-editor and just change "name.png" to
> "name.dds"

Nope, doesn't work.

But this does:

Map the .png file onto the AC3D model as usual -> convert the .png into .dds
in XnView -> load the .dds into AC3D

No flipping of vertical required. 

Perhaps XnView flips it for us?

Vivian



--
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] Adventures in dds

[Vivian Meazza]

Emilian wrote

> 
> On Tuesday 22 March 2011 00:57:07 Vivian Meazza wrote:
> >
> > Nope, doesn't work.
> >
> > But this does:
> >
> > Map the .png file onto the AC3D model as usual -> convert the .png into
> > .dds in XnView -> load the .dds into AC3D
> >
> > No flipping of vertical required.
> >
> > Perhaps XnView flips it for us?
> >
> > Vivian
> Probably xnview sets the origin in the lower left (as is in OpenGL).
> Problem
> with .dds is that each tool used to convert the might set the origin where
> it
> wants :(
> So far I haven't found a way of specifying the origin...

OK - here's what I have discovered:

XnView converts to .dds, and doesn't require flipping, but AFAIKS it doesn't
generate mipmaps either. 

The Gimp (with the dds plug-in) does require that the image is flipped
vertically, but it does generate mipmaps.

Either way I can observe no discernable difference in quality or performance
using a 1024 x 1024 texture on my current .ac model. However, I haven't
carried out any quantative tests. All very interesting, but I'm not sure how
to proceed now. Back to .rgb perhaps? 

Vivian





--
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] 737-100: Fuselagereflect in /Generic ?

[Vivian Meazza]

Heiko wrote:

> 
> 
> > With 737-100 I get a illegal renderbin draw error. This
> > comes from
> > Fuselagereflect.eff (which is not part of 737-100
> > distribution), the
> > effect is in /Aircraft/Generic/Effects. There I see that
> > Fuselagereflect
> > calls default Effects/reflect and then this one has a path
> > to
> > Aircraft/737-300/Models/Effects/733LH.ReflectionMap3.png.
> >
> > Smoke over my head.
> >
> > Cheers, Yves
> >
> 
> I'm not quite sure, but so much as I know that was helijah's idea, as he
> fits every single aircraft with this shader.
> 
> The 733LH.reflectionMap2.png was once created by Vivian and used on the
> 733 to give an example how this shader is working and how it can be jused.
> 
> It would be much better that a gneric ReflectionMap is made and used here.
> That should prevent illegal renderbin draw errors.
> 

If the reflection map path is incorrect you should see only this error
message:

"no image file, maybe the reader did not set the filename attribute, using
white for type '2d' on '', in /technique[9]/pass[0]/texture-unit[4]"

If you are seeing another error message, please update your data (some
potential errors were removed recently). If the errors persist then please
file an issue report. 

The reflection map is intended to vary reflection across an object. I would
be amazed if one size fits all. I wouldn't have expected it to be a good
candidate for the generic folder.

Oddly enough I have been working on the shader today. The reflection map can
be used to give quite nice effects:

ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV-Reflect-Map.png



Vivian



--
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] 737-100: Fuselagereflect in /Generic ?

[Vivian Meazza]

Heiko

> 
> >>About:  An aircraft flying in the alps reflecting very visible the ocean
> >>doesn't look realistic.
> >>Won't it be possible to select the reflection according to the terrain
> >>under, it is done with some particule animations  (helicopter), it is
> >>possible to make it with the reflecting system.
> 
> >>I know that Gerard did experiment it,  unfortunately i havn't found the
> >>example.
> >>It just want to include a Nasal script, since the terrain under is not
> >>exposed within a property.
> 
> I don't think it is possible, as the shader system doesn't allow dynamic
> switching between different cubemaps.
> And then, when ever the aircraft is flying above a small spot of water it
> would switch to ocean-cubemap- even in the alps.
> 
> Better would be a realtime environment map. (like the reflections on the
> water in MSFS X or X-Plane)
> But this needs render-texture support and will probably have some impact
> on perfomance.
> 

The default cube map of fair-sky is a reasonable representation of our
fair-weather sky, with a nondescript land cover. Not only can the cube map
not be changed on the fly, but it is also fixed to the aircraft and not the
environment. If you don't look too closely, we can just about get away with
it over most terrain (even ocean). It would be nice to fix that. RTT would
be even better, but I can't see that getting done at a frame rate that we
can afford.

Hell, we can't even do shadows ... what chance a realistic reflection
shader?


Vivian 



--
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] 737-100: Fuselagereflect in /Generic ?

[Vivian Meazza]

Yves wrote

> Am 28.03.11 00:34, schrieb Vivian Meazza:
> >
> > If the reflection map path is incorrect you should see only this error
> > message:
> >
> > "no image file, maybe the reader did not set the filename attribute,
> using
> > white for type '2d' on '', in /technique[9]/pass[0]/texture-unit[4]"
> >
> 
> I get no missing file errors.
> 
> > If you are seeing another error message, please update your data (some
> > potential errors were removed recently). If the errors persist then
> please
> > file an issue report.
> 
> I reverted all commits from Fred related to the patches from Lauri,
> without success. The issue remains, "OpenGL error" and "invalid
> operation error" after renderbin draw with reflect and reflect-bumpspec.
> All other shaders work as expected. I am on ATI 5750 on OSX 10.6.6.
> 
> I don't see any other changes checked in fgdata or flightgear the last
> weeks. Where should I look else?
> 
> I am tired of this issues (probably only ATI/OSX driver related again?).
> I bought a new ATI 5750 and now I get new errors with the reflect
> shaders. The shaders worked as expected with my very old ATI x1600, hmpf!
> 
> Should I downgrade OSG to 2.9.7, I am currently running 2.9.9. ?
> 

I think you answered this one yourself:

"shaders worked as expected with my very old ATI x1600"

Nothing has been changed in quite a while, apart from Lauri's patch which
makes the shaders more backward compatible. I think you should use the
shader with this patch applied, since it removed unused variables, which are
a potential source of errors.

I'm running 2.9.9 here, but it might be worth trying 2.9.7.

I think "OpenGL error" and "invalid operation error" would indicate a driver
issue, but I'm not an expert. Is anyone else reporting issues with this
shader?

Test using the B29, I'm confident that it works correctly. I'm not sure
about other instances.

I'm sorry I can't help more, but I'm not a mac user.

Vivian 



--
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] Cloud interface from Nasal

[Vivian Meazza]

Thorsten wrote

> 
> > Yes, in fact, my basic strategy was to use the existing default 3D cloud
> > code almost untouched from the perspective of creating a set of sprites
> > that are built up into a cloudlet. So, you can define (amongst other
> > things)
> >
> > - the texture sheet to use,
> > - the number of sprites,
> > - min/max width and height of each sprite,
> > - the width and height of the distorted sphere to place the sprites on.
> > - shading of the bottom of the cloudlet
> > - lat/lon/alt of the cloudlet.
> >
> > I'm sure you are very familiar with the capabilities and limitations of
> > that approach, but it would be worth having a look at the
> README.3dclouds
> > so see the API available. Note that I'm just considering expositng the
> > bottom level cloudlet, so building them up onto multi-part clouds and
> > boxes of clouds will be done externally.
> 
> Sounds good to me - that is basically the functionality I was describing
> at the level of the box where you can specify how many cloudlets you place
> - in your terminology, replace 'box' by 'distorted sphere' and 'cloudlet'
> by 'sprite', but no matter, these are details.
> 
> 
> 
> > To match the existing global 3D clouds, it would be easier for each
> > "cloudlet"
> > (cluster of sprites representing a cloud puff) to use a single texture
> > sheet
> > containing multiple sprite textures.  However, there is control over the
> > uv coordinates of each sprite, where the x-axis is random, but the
> y-axis is
> > controlled by the vertical location of the sprite. So you can create a
> > cloudlet with a mixture of textures, and have a fair bit of control of
> > those textures.
> 
> Mixing is actually not a problem at all - I can just create 2 overlapping
> cloudlets from 2 different texture sheets and place a third with dark
> diffuse bottoms below - that doesn't need to be hard-coded as long as I
> can ask for a texture sheet for each of the building blocks.
> 
> Since my basic Cu texture image is often 1024x512 (sometimes larger),
> sorting through the y-coordinate of the texture sheet isn't an option
> unless you use 4096x4096 sheets - which may not be so nice. (?) Well, I
> guess that depends on the texture cache which you seem to have anyway.
> 
> > We could certainly add new parameters to the shader. I'd prefer to do
> > that rather than generating a number of very similar shaders.
> 
> Yes (in fact, if I would know how to do it from Nasal, I would have done
> it with a single shader and parameters rather than designing 4 different
> ones...).
> 
> If you provide control over cloudlet size as above, I think the main new
> parameter needed is the amount of rescaling in the vertical axis to squash
> cloudlets into startiform shapes.
> 
> > Instead I'm thinking of the creatCloud() call returning some correlator
> > that  can be used by the Nasal client to reposition or delete
> > the cloudlet.
> 
> That's even better, because that gets rid of all the time constraints in
> writing properties into the tree, so the Nasal cloud object can just store
> the identifier returned upon creation, and then use that to reference the
> cloud in the future.
> 
> > which may be important if we have
> > to track
> > thousands of cloudlets, or the Nasal code just wants to create the cloud
> > and then forget about it.
> 
> Then we need to agree who gets to delete clouds. Right now, I keep some
> memory of clouds until the tile is deleted even after removing them from
> the scene, i.e. when you fly for 40 km and then turn by 180 degrees and
> fly back, you get to see the same (modulo some evolution) clouds you had
> when you left. (That's actually important if you pass a weathershed with
> METAR on, see bad weather ahead and decide to turn back - without the
> memory function, bad weather would appear no matter where you fly from th
> eturning point till a new METAR report is received.). But that requires
> that I keep track of what is in the scenery, what is still internally
> represented within Nasal but deleted from the scenery and what has been
> completely erased.
> 
> So maybe there should then be a global switch to tell the system either 'I
> want to create clouds, and I will monitor and delete them myself' or 'I
> just want to create clouds and forget about them, you can delete them
> yourself when I'm out of range'.
> 
> > I'm thinking the base API will be the lon/lat/alt of an individual
> > cloudlet, possibly
> > with an additional x/y offset to save lots of costly calculations when
> > creating a
> > series of cloudlets next to each other .
> 
> Doesn't need an offset if you ask me - that is a natural part of how to
> implement a placement call from Nasal, and that's not a speed bottleneck
> at all.
> 
> > Certainly we could include horizontal movement on a per-layer basis, so
> > you
> > would add a series of clouds to a layer, which would move together.
> 
> After some additional thought, movement *really* adds a can of worms.
> 
> If you group

Re: [Flightgear-devel] 737-100: Fuselagereflect in /Generic ?

[Vivian Meazza]

Emilian wrote

> 
> On Wednesday 30 March 2011 13:57:19 Vivian Meazza wrote:
> > Yves wrote
> >
> > > Am 28.03.11 00:34, schrieb Vivian Meazza:
> > > > If the reflection map path is incorrect you should see only this
> error
> > > > message:
> > > >
> > > > "no image file, maybe the reader did not set the filename attribute,
> > >
> > > using
> > >
> > > > white for type '2d' on '', in /technique[9]/pass[0]/texture-unit[4]"
> > >
> > > I get no missing file errors.
> > >
> > > > If you are seeing another error message, please update your data
> (some
> > > > potential errors were removed recently). If the errors persist then
> > >
> > > please
> > >
> > > > file an issue report.
> > >
> > > I reverted all commits from Fred related to the patches from Lauri,
> > > without success. The issue remains, "OpenGL error" and "invalid
> > > operation error" after renderbin draw with reflect and reflect-
> bumpspec.
> > > All other shaders work as expected. I am on ATI 5750 on OSX 10.6.6.
> > >
> > > I don't see any other changes checked in fgdata or flightgear the last
> > > weeks. Where should I look else?
> > >
> > > I am tired of this issues (probably only ATI/OSX driver related
> again?).
> > > I bought a new ATI 5750 and now I get new errors with the reflect
> > > shaders. The shaders worked as expected with my very old ATI x1600,
> hmpf!
> > >
> > > Should I downgrade OSG to 2.9.7, I am currently running 2.9.9. ?
> >
> > I think you answered this one yourself:
> >
> > "shaders worked as expected with my very old ATI x1600"
> >
> > Nothing has been changed in quite a while, apart from Lauri's patch
> which
> > makes the shaders more backward compatible. I think you should use the
> > shader with this patch applied, since it removed unused variables, which
> > are a potential source of errors.
> >
> > I'm running 2.9.9 here, but it might be worth trying 2.9.7.
> >
> > I think "OpenGL error" and "invalid operation error" would indicate a
> > driver issue, but I'm not an expert. Is anyone else reporting issues
> with
> > this shader?
> >
> > Test using the B29, I'm confident that it works correctly. I'm not sure
> > about other instances.
> >
> > I'm sorry I can't help more, but I'm not a mac user.
> >
> > Vivian
> >
> >
> 
> Happens here if I disable and then reenable the shaders with the view->
> rendering options.

What happens?

> Also most of the "no image file, .." errors go away if I specify paths to
> them
> in the effect that inherits the one from Effects/reflect*
> (inheritance problem ?).

No, it's not inheritance problems. It's people using unchanged copies of
code which is meant to be an example. But I think I can fix it. In any case,
the warnings shouldn't affect the functioning of the shader.

Vivian
 



--
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] 737-100: Fuselagereflect in /Generic ?

[Vivian Meazza]

Emilian
> 
> On Thursday 31 March 2011 12:03:50 Vivian Meazza wrote:
> 
> > >
> > > Happens here if I disable and then reenable the shaders with the view-
> >
> > > rendering options.
> >
> > What happens?
> 
> The render bin error.
> >
> > > Also most of the "no image file, .." errors go away if I specify paths
> to
> > > them
> > > in the effect that inherits the one from Effects/reflect*
> > > (inheritance problem ?).
> >
> > No, it's not inheritance problems. It's people using unchanged copies of
> > code which is meant to be an example. But I think I can fix it. In any
> > case, the warnings shouldn't affect the functioning of the shader.
> >
> > Vivian
> >
> 
> Ok.. so the reflect.eff in $FG_ROOT/Effects is only meant as an example ?
> It should say so. Instead it says it can be inherited.

That's not what I meant. It was the use of
Aircraft/737-300/Models/Effects/733LH.ReflectionMap3 when it is not
appropriate. Reflect.eff can and should be inherited.

> Nevermind that, if I inherit it in an .eff, shouldn't the unchanged
> elements be
> passed to the other .eff ?
> 
 
Yes, and as AFAIKS that works correctly.

I have amended data/Effects/reflect.eff so that it uses a generic example
reflect map, which needs replacing for individual aircraft.

There is one remaining error message which can be generated:

"failed to load effect texture file D:/path/to/your/data/"

This slightly misleading error message is generated when the object that has
the reflection effect applied has no base texture. The effect still works as
expected though. The fix is obviously to apply a base texture.

Vivian 

 



--
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] 737-100: Fuselagereflect in /Generic ?

[Vivian Meazza]

Emilian,

 

I've been devilling around in the IAR80 - something is generating that
error, and I haven't found it yet. It also looks as if the cube cross option
is no longer working here. I'll keep on some more.

 

Vivian

 

-Original Message-
>From Huminiuc [mailto:emili...@gmail.com] 
Sent: 03 April 2011 23:20
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] 737-100: Fuselagereflect in /Generic ?

 

On Monday 04 April 2011 01:00:36 Vivian Meazza wrote:

> Emilian

> 

> > On Thursday 31 March 2011 12:03:50 Vivian Meazza wrote:

> > > > Happens here if I disable and then reenable the shaders with the

> > > > view-

> > > > 

> > > > rendering options.

> > > 

> > > What happens?

> > 

> > The render bin error.

> > 

> > > > Also most of the "no image file, .." errors go away if I specify

> > > > paths

> > 

> > to

> > 

> > > > them

> > > > in the effect that inherits the one from Effects/reflect*

> > > > (inheritance problem ?).

> > > 

> > > No, it's not inheritance problems. It's people using unchanged copies

> > > of code which is meant to be an example. But I think I can fix it. In

> > > any case, the warnings shouldn't affect the functioning of the shader.

> > > 

> > > Vivian

> > 

> > Ok.. so the reflect.eff in $FG_ROOT/Effects is only meant as an example
?

> > It should say so. Instead it says it can be inherited.

> 

> That's not what I meant. It was the use of

> Aircraft/737-300/Models/Effects/733LH.ReflectionMap3 when it is not

> appropriate. Reflect.eff can and should be inherited.

 

I see, thanks for clearing that out :).

 

> 

> > Nevermind that, if I inherit it in an .eff, shouldn't the unchanged

> > elements be

> > passed to the other .eff ?

> 

> Yes, and as AFAIKS that works correctly.

> 

> I have amended data/Effects/reflect.eff so that it uses a generic example

> reflect map, which needs replacing for individual aircraft.

> 

> There is one remaining error message which can be generated:

> 

> "failed to load effect texture file D:/path/to/your/data/"

> 

> This slightly misleading error message is generated when the object that

> has the reflection effect applied has no base texture. The effect still

> works as expected though. The fix is obviously to apply a base texture.

> 

> Vivian

I see, I think i've got a couple of those in the IAR cockpit that might give
me that error :"> 

If it's not too much to ask will you take a look at this:

http://code.google.com/p/flightgear-bugs/issues/detail?id=262

It's very visible in the IAR cokpit. Might be a mistake on my part, but I
haven't got any feedback watsoever :(.

 

 

--
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] 737-100: Fuselagereflect in /Generic ?

[Vivian Meazza]

Emilian,

 

After some investigation, it is all working as expected. Here is a
demonstration of all the possible features of bump mapping, reflections,
reflection mapping, cube maps and cube crosses all working together.

 

 <ftp://abbeytheatre2.org.uk:2121/flightgear/IAR80/iar80-mapped.png>
ftp://abbeytheatre2.org.uk:2121/flightgear/IAR80/iar80-mapped.png

 

I've found some, but not all, of the objects with no texture but with
reflection applied. Later I will put the amended files where you can
download them so that you can adjust the parameters to your own
satisfaction.

 

Vivian

 

 

-Original Message-
From: Vivian Meazza [mailto:vivian.mea...@lineone.net] 
Sent: 04 April 2011 13:56
To: 'FlightGear developers discussions'
Subject: RE: [Flightgear-devel] 737-100: Fuselagereflect in /Generic ?

 

Emilian,

 

I've been devilling around in the IAR80 - something is generating that
error, and I haven't found it yet. It also looks as if the cube cross option
is no longer working here. I'll keep on some more.

 

Vivian

 

-Original Message-
>From Huminiuc [mailto:emili...@gmail.com] 
Sent: 03 April 2011 23:20
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] 737-100: Fuselagereflect in /Generic ?

 

On Monday 04 April 2011 01:00:36 Vivian Meazza wrote:

> Emilian

> 

> > On Thursday 31 March 2011 12:03:50 Vivian Meazza wrote:

> > > > Happens here if I disable and then reenable the shaders with the

> > > > view-

> > > > 

> > > > rendering options.

> > > 

> > > What happens?

> > 

> > The render bin error.

> > 

> > > > Also most of the "no image file, .." errors go away if I specify

> > > > paths

> > 

> > to

> > 

> > > > them

> > > > in the effect that inherits the one from Effects/reflect*

> > > > (inheritance problem ?).

> > > 

> > > No, it's not inheritance problems. It's people using unchanged copies

> > > of code which is meant to be an example. But I think I can fix it. In

> > > any case, the warnings shouldn't affect the functioning of the shader.

> > > 

> > > Vivian

> > 

> > Ok.. so the reflect.eff in $FG_ROOT/Effects is only meant as an example
?

> > It should say so. Instead it says it can be inherited.

> 

> That's not what I meant. It was the use of

> Aircraft/737-300/Models/Effects/733LH.ReflectionMap3 when it is not

> appropriate. Reflect.eff can and should be inherited.

 

I see, thanks for clearing that out :).

 

> 

> > Nevermind that, if I inherit it in an .eff, shouldn't the unchanged

> > elements be

> > passed to the other .eff ?

> 

> Yes, and as AFAIKS that works correctly.

> 

> I have amended data/Effects/reflect.eff so that it uses a generic example

> reflect map, which needs replacing for individual aircraft.

> 

> There is one remaining error message which can be generated:

> 

> "failed to load effect texture file D:/path/to/your/data/"

> 

> This slightly misleading error message is generated when the object that

> has the reflection effect applied has no base texture. The effect still

> works as expected though. The fix is obviously to apply a base texture.

> 

> Vivian

I see, I think i've got a couple of those in the IAR cockpit that might give
me that error :"> 

If it's not too much to ask will you take a look at this:

http://code.google.com/p/flightgear-bugs/issues/detail?id=262

It's very visible in the IAR cokpit. Might be a mistake on my part, but I
haven't got any feedback watsoever :(.

 

 

--
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] 737-100: Fuselagereflect in /Generic ?

[Vivian Meazza]

Emilian wrote 

> On Tuesday 05 April 2011 11:35:38 Vivian Meazza wrote:
> > Emilian,
> >
> >
> >
> > After some investigation, it is all working as expected. Here is a
> > demonstration of all the possible features of bump mapping, reflections,
> > reflection mapping, cube maps and cube crosses all working together.
> >
> >
> >
> >  <ftp://abbeytheatre2.org.uk:2121/flightgear/IAR80/iar80-mapped.png>
> > ftp://abbeytheatre2.org.uk:2121/flightgear/IAR80/iar80-mapped.png
> >
> >
> >
> > I've found some, but not all, of the objects with no texture but with
> > reflection applied. Later I will put the amended files where you can
> > download them so that you can adjust the parameters to your own
> > satisfaction.
> >
> >
> >
> > Vivian
> :) I know it's working. The "dull" reflection on the default livery is
> intentional, as camo paint wasn't very shiny. The "no image file" errors
> went
> away anyway, as I've converted the model to use .dds maps, and was forced
> to
> specify paths to all the textures, as I will provide local copies of them
> ,
> converted to .dds.
> 
> Thanks anyway :). But the problem I was asking you to take a look at was a
> bit
> different :
> 
> Problem was in the cockpit, there are some full black faces on objects I
> know
> are correctly mapped (and I can easily reproduce the problem with any
> object
> that's using the reflect shader and has a perfectly vertical face), and I
> was
> asking you to take a look and see if you can reproduce the bug on your
> end.
> (Maybe it's system/gpu specific).
> Also you can see a weird black rectangle reflected by the pilot seat if
> you
> look straight down. (or at least that's what I see here). It looks as if
> one
> face of the reflected "cube" is smaller than the other .
> And before you ask, problem isn't related nor fixed by .dds textures (it
> looks
> just the same no matter what type of texture I use).

Actually - it wasn't working correctly - you are using a cube cross texture
with cube map shader - which, much to my surprise works after a fashion.

I'll investigate further.

Vivian



--
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] 737-100: Fuselagereflect in /Generic ?

[Vivian Meazza]

Emilian wrote

> 
> On Tuesday 05 April 2011 19:07:10 Vivian Meazza wrote:
> 
> >
> > Actually - it wasn't working correctly - you are using a cube cross
> texture
> > with cube map shader - which, much to my surprise works after a fashion.
> >
> > I'll investigate further.
> >
> > Vivian
>  Ooops, I left the cube cross on the fuselage shader on the released
> version,
> my bad. Missed that, probably because it was working.
> 
> 
> I was refering at the reflect shader used by the cockpit. Please check
> this
> picture:
> http://ompldr.org/vODRxcw
> 
> Thanks for looking into this.

The dark patches are an artifact of the reflection of a dark area of the
reflection texture, and of the geometry of the object.  It only happens in
one direction. It's worse on a flat surface. I can't find a way to stop that
in the code. I think we will have to live with this one.

They can be removed, or at least hidden, by using more surfaces, and or
triangulation. I found and fixed one on the Mixture Lever knob. 

ftp://abbeytheatre2.org.uk:2121/flightgear/IAR80/iar80-mixture.png


> Btw: I think the Tempest looks great, and it's a shame to use such a small
> texture, please consider using at least 2048x2048 ;)

Thank you for that. Now that I have looked in detail at the IAR80, I am
impressed by your attention to detail, and that even with all the detail, a
reasonable framerate can be maintained. Now back to the Tempest to see if I
can do as well.

Vivian





--
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] Hurricane gearDown() and gearToggle() Nasalfunctions

[Vivian Meazza]

Catherine James wrote

> -Original Message-
> From: [mailto:catherine.ja...@att.net]
> Sent: 08 April 2011 04:30
> To: flightgear-devel@lists.sourceforge.net
> Subject: [Flightgear-devel] Hurricane gearDown() and gearToggle()
> Nasalfunctions
> 
> 
> It absolutely drove me nuts that the Hurricane, alone of the planes I've
> tried, does not retract the gear when I press the appropriate joystick
> button.  Studying the Nasal code, I saw that the gearDown() function was
> overridden in the Aircraft/Hurricane/Models/hurricane.nas file.
> 
> Changing about five lines fixes the problem.  Is anyone interested in
> testing and hopefully committing this change into GIT?  I have tested it
> on the current GIT master branch build, but not the GIT next build.
> 
> Replace the gearDown() function in hurricane.nas with the following code:
> 
> controls.gearDown = func(x) {
>hydraulicLever(-1, -x);
>hydraulicLever(-1, -x);
> }
> 
> controls.gearToggle = func {
>controls.gearDown(getprop("/controls/hydraulic/wheels") > 0 ? -1 : 1);
> }
> 

Absolutely not - it is not a bug but a feature. Moving the lever operates
the wheel retraction, not some joystick button. Either use G or pick the
lever in the cockpit. And return it to neutral on completion, or the flaps
will not operate. 

Vivian



--
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] Pacific Northwest Scenery Available

[Vivian Meazza]

Martin wrote:

> Ron Jensen wrote:
> 
> > Martin: Can we PLEASE ungzip apt.dat in the repository so we can track
> changes
> > to it!
> 
> The GIT repository you mean ? Ask those who decided do put a compressed
> file there, _I_ am just continuing an old tradition.
> 

Don't we unzip all the navaids stuff on the fly? I put carrier_nav.dat and
TACAN-freq.dat in there as zipped files on that understanding. A long time
ago, mind, I might have it all wrong.

Vivian 



--
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] Simple atmospheric scattering shader for skydome

[Vivian Meazza]

Lauri wrote

> 
> Hi,
> 
> I made this patch some time ago, and seems like it is working quite
> fine, so I though if it might be possible to add to git (if nothing
> more, then maybe for future reference)?
> 
> It does two things. First I modified the skydome code to be more
> configurable so that the precision could be increased (number of rings
> and bands). Then I implemented the O'Neil's scattering shader to
> showcase the scattering. I know that for the proper effect, terrain and
> other objects should use the same shader, but that is probably future
> work.
> 
> Anyways, here are links to patches and effects. The flightgear patch
> only makes clearcolor black, so that space is dark instead of gray.
> 
> http://users.tkk.fi/~lapelto2/fgfs/scatter/scatter-simgear.patch
> http://users.tkk.fi/~lapelto2/fgfs/scatter/scatter-flightgear.patch
> 
> http://users.tkk.fi/~lapelto2/fgfs/scatter/skydome.eff
> http://users.tkk.fi/~lapelto2/fgfs/scatter/skydome.frag
> http://users.tkk.fi/~lapelto2/fgfs/scatter/skydome.vert
> 
> Screenshots can be found from the forum thread:
> http://www.flightgear.org/forums/viewtopic.php?f=47&t=11274&p=117965#p1179
> 65
> 
> And the command line to run the shader, it needs some properties set:
> fgfs --prop:/sim/rendering/mie=0.003
> --prop:/sim/rendering/rayleigh=0.0003
> --prop:/sim/rendering/dome-density=0.5
> --prop:/sim/rendering/scattering-shader=1

Nice work. I'm not entirely sure about the colours, but that might be a
local issue:

ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/Tempest-skydome-shader.pn
g
 
> The non-shader version should look just like it used to, but on some
> occasions I think the sunset effect is a bit misplaced. I didn't touch
> that code, so was it always like that? Can someone verify?

This bug?

http://code.google.com/p/flightgear-bugs/issues/detail?id=182&can=1&start=10
0

It's meant to have been fixed.

I can push the shader and effects file into git - but someone else will have
to pick up the flightgear and simgear patches

Vivian





--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Simple atmospheric scattering shader forskydome

[Vivian Meazza]

Heiko wrote

> -Original Message-
> From: Heiko Schulz [mailto:aeitsch...@yahoo.de]
> Sent: 12 April 2011 23:18
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Simple atmospheric scattering shader
> forskydome
> 
> 
> > It does two things. First I modified the skydome code to be
> > more
> > configurable so that the precision could be increased
> > (number of rings
> > and bands). Then I implemented the O'Neil's scattering
> > shader to
> > showcase the scattering. I know that for the proper effect,
> > terrain and
> > other objects should use the same shader, but that is
> > probably future
> > work.
> 
> The shader can be switched off, right? It doesn't make sense to use it
> when a lot of things still missing.

--prop:/sim/rendering/scattering-shader=0

Vivian



--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Simple atmospheric scattering shader for skydome

[Vivian Meazza]

Erik wrote

> 
> On Thu, 2011-04-14 at 18:15 +0200, Durk Talsma wrote:
> 
> >
> > Okay, thanks for the comments. I'll be holding back on committing. Is
> > there any perspective that this patch can be brought to production
> > quality?
> 
> I'm not sure, it needs time to look after some things. For one it should
> be made possible for the shader to adjust the fog color located
> under /rendering/fog but at this time values written to it will be
> overwritten by the current code.
> 

I added some sliders in the rendering dialog here as suggested by Fred and
did some adjustments at runtime. There do seem to be some issues that I was
unable to tune out - at least so far:

ftp://abbeytheatre2.org.uk:2121/flightgear/Skydome/

However, I am concerned that if we do not get this into git, it will get
forgotten, and we will not get the potential improvements. That said, there
do seem to be some pretty fundamental problems here, as the screenshots
indicate.

I can't see any downside here - if the shader is disabled - so far as I can
see the existing skydome is unaffected. 

Vivian



--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Simple atmospheric scattering shader forskydome

[Vivian Meazza]

Durk wrote

> 
> On 15 Apr 2011, at 08:41, Erik Hofman wrote:
> 
> > On Fri, 2011-04-15 at 00:16 +0200, Christian Schmitt wrote:
> >> I can only agee with Vivian here: lets get this change into GIT, so
> that it
> >> doesn't get lost as so many others in the past. The shader is not
> perfect
> >> yet, but that should not hurt, as it is disabled as a default. Those
> who
> >> want to test and improve it are free to do so.
> >> Let me add that it's good to have people who work on things like
> shaders (we
> >> need every single one of them).
> >
> > I'm not opposed to adding the shaders but I want a good look at the code
> > to make sure that current functionality is not lost with the patch
> > before it gets committed.
> >
> 
> Like, Christian and Vivian stated earlier, I would also hate to see a
> patch getting lost, especially when it contains promise.  This is why I
> originally suggested committing it.
> 
> I would suggest that (even though it may not be production-ready yet), we
> commit the patch on the condition that; 1) the shader in question is
> disabled by default, and 2) in its disabled state doesn't have an adverse
> impact .
> 
> Thoughts / Ideas?
> 

I'm just putting together a data commit to do just that. But it will still
need the Fg/SG patches

Vivian 



--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] XML formating Was: [Flightgear-commitlogs] FlightGear Base Package branch, master

[Vivian Meazza]

Fred wrote

> 
> Is it wise to reformat preferences.xml with a tab length set to 2 ? see
> below :
> 
> Le 15/04/2011 22:19, Flightgear-commitlogs a écrit :
> > - Diff 
> >
> > diff --git a/preferences.xml b/preferences.xml
> > index 342734e..8612a78 100644
> > --- a/preferences.xml
> > +++ b/preferences.xml
> > @@ -65,10 +65,14 @@ Started September 2000 by David Megginson,
> da...@megginson.com
> > false
> > 5
> > 8
> > -   0.003
> > -   0.0003
> > -   0.5
> > -   0
> > +> +userarchive="y">0.003
> > +> +
>   userarchive="y">0.0003
> > +> +
>   userarchive="y">0.5
> > +> +
> userarchive="y">0
> > 
> > 

Re: [Flightgear-devel] XML formating Was: [Flightgear-commitlogs] FlightGear Base Package branch, master

[Vivian Meazza]

> -Original Message-
> From: Frederic Bouvier [mailto:fredfgf...@free.fr]
> Sent: 16 April 2011 11:52
> To: vivian meazza; FlightGear developers discussions
> Subject: Re: [Flightgear-devel] XML formating Was: [Flightgear-commitlogs]
> FlightGear Base Package branch, master
> 
> 
> - "Vivian Meazza"  a écrit :
> 
> > Fred wrote
> >
> > >
> > > Is it wise to reformat preferences.xml with a tab length set to 2 ?
> >
> > Well, it's better than the current mess of spaces and tabs. At least
> > we can now read it.
> 
> *You* can read it with your own MSVC preferences

Yes, I know that very well. But I hate a mess - it looks unprofessional. I'd
fix up the rest of the mess given half a chance.

Vivian



--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Vostok-1

[Vivian Meazza]

Gene couldn't resist

> -Original Message-
> From: Buckle [mailto:ge...@deltasoft.com]
> Sent: 17 April 2011 16:19
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Vostok-1
> 
> On Sun, 17 Apr 2011, Torsten Dreyer wrote:
> 
> > > Merge commit 'refs/merge-requests/84' of
> > git://gitorious.org/fg/fgdata into integration
> > >
> > > commit 4a25745ea96dac35a1069a2f85f0b6e72e38ed14
> > > Author: Victor Slavutinsky
> > > Date: Wed Apr 13 16:19:53 2011 +0400
> >
> > > 1) Initial adding of Vostok-1 spacecraft and carrier.
> >
> > $ du -hs Vostok-1/
> > 156MVostok-1/
> >
> > 156MB!? Isn't that a bit - huge?
> >
> It's a big rocket. :)
> 
> 
> Sorry, couldn't resist.
> 

Wrong - it's a bloody enormous rocket :)

V.



--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Vostok-1

[Vivian Meazza]

Jon wrote:

> -Original Message-
> From: S. Berndt [mailto:jonsber...@comcast.net]
> Sent: 17 April 2011 18:10
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Vostok-1
> 
> What perfect timing for this model too, given the recent 50th anniversary
> of Yuri Gagarin's first human spaceflight.
> 

We were busting a gut to get it into Gitorious on the very day.

Vivian



--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Vostok-1

[Vivian Meazza]

Jon wrote:

> -Original Message-
> From: S. Berndt [mailto:jonsber...@comcast.net]
> Sent: 17 April 2011 18:10
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Vostok-1
> 
> What perfect timing for this model too, given the recent 50th anniversary
> of Yuri Gagarin's first human spaceflight.
> 

We were busting a gut to get it into Gitorious on the very day.

Vivian



--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Future repository for non-GPL aircraft

[Vivian Meazza]

Ryan M wrote

 
> Something I've always thought about is an official aircraft repository
> that contained non-GPL2 aircraft- straight from the authors, of course.
> There are many aircraft for FlightGear that are not GPL-licensed (some
> of them very well-developed, like the Tu-154b and the MD-81), and I
> think it'd be best if we had an official repository for them. Currently,
> they are hosted on a number of unofficial "hangars," decreasing their
> visibility and their accessibility to the end-user.
> 
> This discussion has been raised before on the forums; just thought I'd
> mention it here. Sorry if there's been a previous conversation about
> this and I've resurrected a dead topic.
> 

I don't think this has been raised for a while, if at all. It could be a
good idea, if there really is a demand for it. Conceptually it is another
external "hangar", but with "official" status. It would need some people to
maintain it, but I guess you would volunteer yourself, and to organize
others to help?

I can't think of any downside right now. 

Vivian



--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] RFC: fgdata merge request 76: Improvedairport Textures

[Vivian Meazza]

I'm afraid that the "improved textures" really aren't an improvement. Not
only do they not work for taxiways, we have also lost the chevrons at the
threshold that were quite recently added: 

 

https://picasaweb.google.com/gijsrooy/FlightGearSkyopSTextures#5604420979421
192098 

 

The grass isn't much of an improvement either. On balance, this upload is a
regression. IMO we should back it out.

 

Vivian

 

-Original Message-
From: Durk Talsma [mailto:durkt...@gmail.com] 
Sent: 07 May 2011 09:39
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] RFC: fgdata merge request 76:
Improvedairport Textures

 

Whoops,

should have been: (request #61).

https://gitorious.org/fg/fgdata/merge_requests/61

(Need more coffee, need more coffee, need more coffeee . :-) )

D.

 

On 07 May 2011, at 10:35, Durk Talsma wrote:





Hi all,

Going through the list of open merge requests for fgdata, I noticed that
this one is still open:

https://gitorious.org/fg/fgdata/merge_requests/76

One person, other than the author commented positively on the new textures
in question (in addition to receiving generally positive comments on the
forum), so I would be inclined to accept this merge request, but I cannot
really judge if there are any side effects? Any objections?

Cheers,
Durk

 

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] RFC: fgdata merge request 76: Improvedairport Textures

[Vivian Meazza]

Ryan M

> -Original Message-
> From: Ryan M [mailto:tpbspamm...@gmail.com]
> Sent: 10 May 2011 03:46
> To: vivian.mea...@lineone.net; FlightGear developers discussions
> Subject: Re: [Flightgear-devel] RFC: fgdata merge request 76:
> Improvedairport Textures
> 
> On Sun, 2011-05-08 at 23:46 +0100, Vivian Meazza wrote:
> > I'm afraid that the "improved textures" really aren't an improvement.
> > Not only do they not work for taxiways, we have also lost the chevrons
> > at the threshold that were quite recently added:
> 
> Really? I certainly did *not* touch the stopway textures- I just copied
> the high-resolution stopway textures, scaled them down, and put them
> into the low-resolution folder. If they were removed, I'm not sure what
> happened. I didn't do that in my commit.
> 
> Stopway textures have been around for quite some time, but they were
> missing from materials.xml. I was the one who made that fix. :)
> 
> As for them not looking good at all, most people agree that the grass is
> an improvement. Perhaps you could tell me what, specifically, is wrong
> with it. Is it too bright? Too bland? Too repetitive?
>

The main problem is that the taxiway textures expose the workaround that we
use because we don't (yet) have curved taxiways. The concrete colour does
not blend with the old texture, which is still used for aprons etc., and the
edge and centre lines also serve to emphasize the problem. Here are a couple
of examples. 

ftp://abbeytheatre2.org.uk:2121/flightgear/Terrain/EGMH-textures.jpg

ftp://abbeytheatre2.org.uk:2121/flightgear/Terrain/EGMH-textures-2.jpg

Note the lack of stopways. Presumably something went wrong with the merge.
See how every segment of the taxiways is obvious. The colour of the grass is
probably a matter of opinion, but note how it fails to merge with the
surrounding textures, exposing the cut-in edge of the airfield. I'm very
sorry, but IMO this all looks rather unprofessional. I would not wish to
release this as it stands.

Vivian 




--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] RFC: fgdata merge request 76:Improvedairport Textures

[Vivian Meazza]

Christian Schmitt wrote

> 
> Vivian Meazza wrote:
> 
> 
> > The main problem is that the taxiway textures expose the workaround that
> > we use because we don't (yet) have curved taxiways. The concrete colour
> > does not blend with the old texture, which is still used for aprons
> etc.,
> > and the edge and centre lines also serve to emphasize the problem. Here
> > are a couple of examples.
> 
> I really don't see the problem here. The new textures look nicer as they
> have a slightly different colour than the apron. This looks more like
> planes
> are taxiing there and leave some tire traces behind.
> 
> > Note the lack of stopways. Presumably something went wrong with the
> merge.
> > See how every segment of the taxiways is obvious. The colour of the
> grass
> > is probably a matter of opinion, but note how it fails to merge with the
> > surrounding textures, exposing the cut-in edge of the airfield. I'm very
> > sorry, but IMO this all looks rather unprofessional. I would not wish to
> > release this as it stands.
> >
> 
> The stopways still work for me here, so there is maybe something wrong in
> your fgdata?
> The taxiways in your screenshot surely look ugly but that's more due to
> the
> fact that they are not correctly ordered in the apt.dat file. It's not a
> problem of the new textures.
> I'm sorry, but I can't reproduce those problems here
> 

Yes they do look ugly, because the new textures expose problems that are
hidden by the old ones. Here are some more:

ftp://abbeytheatre2.org.uk:2121/flightgear/Terrain/KSFO-Textures.jpg
ftp://abbeytheatre2.org.uk:2121/flightgear/Terrain/KSFO-Textures-1.jpg
ftp://abbeytheatre2.org.uk:2121//Terraflightgearin/KSFO-Textures-2.jpg

These are not ordering problems - these are errors. And they are not in any
old airport which I happened to find - they are at KSFO. Who is going to
find and correct all these errors? I think these errors, while minor, give
our primary airport an unacceptable appearance, and make the sim look
unprofessional. We have enough errors and omissions in our airports without
actually introducing more

I have absolutely up-to-date data and source from Git here - still no
stopways. Is your data up-to-date? But I suspect that the error is local,
since there are no other reports of this problem.

Vivian 



--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] RFC: fgdata merge request 76:ImprovedairportTextures

[Vivian Meazza]

Csaba Halász wrote

> -Original Message-
> From: Csaba Halász [mailto:csaba.hal...@gmail.com]
> Sent: 11 May 2011 23:01
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] RFC: fgdata merge request
> 76:ImprovedairportTextures
> 
> On Wed, May 11, 2011 at 11:24 PM, Heiko Schulz 
> wrote:
> >>
> >> Anybody got a screenshot with stopways?
> >
> > Yep:
> > www.hoerbird.net/fgfs-screen-251.jpg
> 
> Thanks! Apparently I have to use the scenery from fgdata and not
> terrasync. With that, I have stopway with both the old and the new
> textures.
> 

Yup, problem solved - the stopways aren't in the terrasync repo. They are in
data/Scenery. Perhaps they are in the downloaded scenery - but I'm not going
looking.

Vivian 



--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] heads up: FlightGear release plan

[Vivian Meazza]

Torsten wrote

> 
> during this year's LinuxTag, Martin Spott, Mathias Fröhlich, Thorsten
> Brehm
> and myself developed a strategy and a concept about how to kick out new
> releases of FlightGear on a regular schedule.
> 
> Please find our first draft here:  http://wiki.flightgear.org/Release_Plan
> 
> For the impatient reader, this is the abstract:
> We plan to have two releases per year, one in February, one in August. The
> first scheduled release following this concept will be 2.4.0 in August
> this
> year, 2.6.0 is scheduled for February 2012.
> 
> If no major objections arise, we will set the version number on the
> current
> development stream to 2.3.0 and will call out a "feature freeze" on June
> 17th.
> 
> Any comment and certainly any help for actually preparing the release is
> welcome.
> 

It's as good a plan as any other. However we missed the last planned release
(2.2.0). I'm unaware of the reason(s), but I assume that release is dead. So
I think the question we have to ask is not "when" but "how". Until that is
solved, the "when" is pretty meaningless. 

Nevertheless, having a plan at all is a good start.

Vivian





--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Flightgear-devel Digest, Vol 61, Issue 10

[Vivian Meazza]

Oliver Fels

> 
> > All this is absolutely false. I never  requested a change in the FDM
> > Alouette 2 ! If I could not fly, and although it does not bother me.
> > JM-26 and many, many others were sad not to do so.
> 
> The point with the AlouetteII is that it is a helicopter with absolute no
> stabilisation or control compensation aids the same way as the R22 is-
> just with a higher mass, a turbine and more power.
> 
> Thus if you apply control you will have to make sure that you apply
> compensation on each (!!!) axes simultaneously.
> That makes a helicopter beginner struggle with the controls and propably
> fail but does not make the FDM unrealistic.
> At least it is a (legacy) helicopter with all its challenges.
> If you have not seen an unstable AlouetteII upon takeoff (as you mentioned
> in the other post) this is simply the case because you are watching a
> trained pilot, not a simplistic FDM.
> Thereore before changing the FDM in FlightGear to please the not-so-
> trained pilots I would have appreciated to ask some of the more
> experienced pilots regarding their impressions.
> As to my experiences with the Alouette2 I can say that I can apply stable
> hovers with minimum locational deviations and that I once landed the thing
> stable in the bay of a FlightGear carrier. Things you can not accomplish
> with a broken FDM. Though I have not checked it for a while.
> However the floats version seems to have some issues with CoG and high
> speed flight.
> 
> So I am somehow surprised regarding the latest happenings and do not
> appreciate the way the FDM was changed without a concensus to do so.
> 

As one of the few, or possibly the only one, involved in FG to have stick
time (just a few hours) on helos of this era, I can say that the old fdm
feels pretty realistic, so far as I can recall. It is flyable, and actually
not too difficult. I would say Maik did a pretty good job.

I think that the solution of having easy/hard fdms is a good compromise,
although personally, I can't think why anyone would want to fly an
unrealistic fdm. After all - realism is what FG is all about.

This thread has gone on too long, and there has been far too much said of a
personal nature. It has not reflected well on anyone, and not on the ethic
of this list, nor on FG. Time to call a halt.

Vivian 



--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Flightgear-devel Digest, Vol 61, Issue 12

[Vivian Meazza]

Stuart wrote

> 
> On Wed, May 25, 2011 at 9:19 AM, I wrote:
> > On Tue, May 24, 2011 at 6:37 PM, Hal V. Engel wrote:
> >> I used it for the P-51D and found the system to be easy to use and it
> took
> >> all of perhaps 10 to 15 minutes to create ratings for the four areas
> that
> >> get scored and then create the entries in the *set.xml file. The system
> is
> >> easy to use and for less advanced models should only take perhaps 5
> minutes
> >> to do. More advanced models take a little more effort but the system is
> >> clearly not burdensomeness for aircraft authors to implement.
> >>
> >> The real issue is to get a consensus with in the aircraft author
> community
> >> to use a standardized rating system like this and I don't think this
> has
> >> happened yet. Once there is wide spread agreement on something like
> this it
> >> should fall into place fairly quickly.
> >>
> >> One thing that might be stalling this is that there is currently no
> >> published description of the proposed system (I will call it Stuart's
> >> system) available other than searching this email list and a few things
> on
> >> the forum. At one point Stuart said he would create a document that
> covers
> >> his system but this has not happened yet and the only way to find it is
> to
> >> search the archives and even then the information is spread over a
> number of
> >> emails. Making things even more confusing there is a wiki page on this
> >> subject
> >>
> >> http://wiki.flightgear.org/index.php/Formalizing_Aircraft_Status
> >>
> >> which does not cover Stuart's system but rahter a totally differnt
> system.
> >> In fact the system proposed on the wiki is more complex and has no
> details
> >> on how the ratings would be made unlike Stuart's system. The details on
> how
> >> to rate various things is one of the key aspects of Stuart's system
> along
> >> with it's relative simplicity. Perhaps we can get the wiki page so that
> it
> >> reflects Stuart's system?
> >
> > Thanks for the poke. I completely forgot to write this up.
> >
> > I'll try to do this today, though it needs a proper name.
> 
> This is done. I've gone ahead and replaced the article completely with
> the rating system described in December.
> 
> Now I'm off to rate all the aircraft I maintain!
> 

Thanks for addressing the points that were hammered out over on the IRC
channel. I think the modified system could work. Just a few points remain:

There is no penalty for including systems, such as an AP, where none existed
on the original.

The use of shaders etc. may or may not enhance the realism of the model and
in some cases could be used inappropriately. This is a subjective
assessment, and perhaps could be removed from the points system.

Livery support is not necessarily an enhancement - it is not appropriate for
all models.

I'm not clear if you are awarding points for underwing stores and the like.

We have additional features such as co-pilot/RIO over MP, Wingmen, Formation
Control, Tutorials, Aircraft Specific Help, Contrails, Vapour Trails, and
there are probably some I missed.

And finally - the points system could award a high status to a poor model -
there are no points awarded for the accuracy or the fidelity of the 3d
model. E.G there is at least one model with afterburners modelled where none
existed.

Oh and, finally finally - the model with the highest score might be so good
that the framerate means that it can only be used on high-end systems or
away from detailed airports. This limitation should be noted somewhere.

Let's hope that this tool can help to bring some order out of the current
chaos.

Vivian



--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Rating System Redux (was Re: Flightgear-devel Digest, Vol 61, Issue 12)

[Vivian Meazza]

Stuart

> 
> > Thanks for addressing the points that were hammered out over on the IRC
> > channel. I think the modified system could work. Just a few points
> remain:
> >
> > There is no penalty for including systems, such as an AP, where none
> existed
> > on the original.
> 
> There's not an explicit penalty. but I think Hal has addressed this in
> the notes
> for the System criteria:
> 
> "Ignore systems not present on the aircraft IRL. If the real aircraft
> doesn't have
> a system (e.g. autopilot), the FG model shouldn't have either and if
> all systems
> in the real aircraft are modeled then it scores a 5 even if it is a
> very simple aircraft. "
> 
> I'm not sure how much of a problem this is.  If someone chooses not to
> disable the
> generic autopilot for a vintage aircraft, it will have no effect on
> pilots who choose
> to fly realistically (they simply won't use it). If the system is
> exposed in the cockpit,
> then it is covered by the rating for accuracy of cockpit - a KAP140 in
> the Sopwith
> Camel would obviously not be worth a 4 or 5 cockpit rating. 


That is correct - but it doesn't follow from the criteria quoted above. 

> I don't think it's unreasonable for vintage aircraft to have access to
> a radio, for
> example. A modern pilot flying a vintage aircraft would carry a hand-held.

Yes - it depends on whether we are modeling the original, or a currently
flying example. I've never quite made up my mind on that one.

> 
> > The use of shaders etc. may or may not enhance the realism of the model
> and
> > in some cases could be used inappropriately. This is a subjective
> > assessment, and perhaps could be removed from the points system.
> >
> > Livery support is not necessarily an enhancement - it is not appropriate
> for
> > all models.
> 
> We're talking here about the difference between a 4 or 5 External
> Model rating, where
> we're trying to differentiate between a good external model and one that
> is as
> realistic as possible.
> 
> I think we should differentiate between them if possible, but I'm
> struggling to think
> up some objective criteria. Photo-realistic? model resolution of 5cm?
> 
> Perhaps we end up providing subjective criteria, or some additional
> guidance
> in this case?

I think guidance - livery shouldn't be a criterion for realism, but it might
form part of it. Realism is the goal. 

> 
> > I'm not clear if you are awarding points for underwing stores and the
> like.
> 
> Hadn't thought about that at all. I've added it to the criteria for a
> "4" rating.
> 
> > We have additional features such as co-pilot/RIO over MP, Wingmen,
> Formation
> > Control, Tutorials, Aircraft Specific Help, Contrails, Vapour Trails,
> and
> > there are probably some I missed.
> 
> Contrails & Vapour trails should probably be covered by the external
> model, I think.
> I could add them (along with tyre smoke) as criteria for a Model 5 rating?

Yes - tyre smoke is a generic facility - there is no reason for it not being
added to a model.

> I don't have a good answer for the other items. Some are nice-to-haves
> that enrich
> the simulation experience but don't impact simulation of flight
> itself, but others
> (such as a co-pilot) are more important for multi-crew aircraft.

Call them all "advanced features". That could be a/the criterion for
"advanced production"
 
> > And finally - the points system could award a high status to a poor
> model -
> > there are no points awarded for the accuracy or the fidelity of the 3d
> > model. E.G there is at least one model with afterburners modelled where
> none
> > existed.
> 
> I've updated the external model to include the world "Accurate" for
> ratings 3-5.

Good
 
> Of course, we're trusting that aircraft developers are going to apply the
> rating
> criteria accurately to the best of their ability.

Yes - I think perhaps a bit of spot-checking to keep us all honest?
 
> > Oh and, finally finally - the model with the highest score might be so
> good
> > that the framerate means that it can only be used on high-end systems or
> > away from detailed airports. This limitation should be noted somewhere.
> 
> I don't have a good answer to that. Does that become criteria for a "5" in
> External Model? I think this ends up back as something subjective.


I think we need some form of bench-mark - perhaps the default model at KSFO
with certain (all?) features enabled. The aircraft to be rated scores a %
framerate above or below this norm? Thinking aloud here a bit. Perhaps
that's a bit too fancy.
 
> > Let's hope that this tool can help to bring some order out of the
> current
> > chaos.
> 
> We can but try. Certainly this seems to have a bit more momentum behind it
> than previous attempts, based on the feedback here and on IRC.
> 
> If enough people rate their aircraft and we can use it to provide a better
> download page for the upcoming release, it will succeed.
> 

Let's hope - some aircraft developers have an awful lot of aircraft to rate.

Re: [Flightgear-devel] SimGear compilation problem with MS VisualStudio10

[Vivian Meazza]

Claus Christmann wrote

> 
> Hello all,
> 
> I am trying to build FG in Windows 7, using Visual Studio 10. A part of
> that process is simgear, and that gives me some trouble...
> 
> I eliminated all compile errors with the exception of this one:
> 
> 1>c:\users\claus\desktop\flighgear-dependencies\simgear-
> 2.0.0\simgear\scene\material\effectbuilder.hxx(134): error C2440:
> 'specialization' : cannot convert from 'std::string
> std::_Pair_base<_Ty1,_Ty2>::* ' to 'std::string std::pair<_Ty1,_Ty2>::* '
> 1>  with
> 1>  [
> 1>  _Ty1=std::string,
> 1>  _Ty2=osg::StateSet::RenderingHint
> 1>  ]
> 1>  Standard conversion from pointer-to-member of base to pointer-
> to-member of derived is not applied for template arguments
> 
> Googeling only brings up https://svn.boost.org/trac/boost/ticket/3106
> which unfortunately doesn't help me much. I am using boost 1.46.1.
> 
> Any ideas?
> 

I'm still using boost 1.37.0 - it might be worth trying an earlier version


Vivian



--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] fgdata merge request 91:Animated Jetways

[Vivian Meazza]

Ryan M wrote

> -Original Message-
> From: [mailto:tpbspamm...@gmail.com]
> Sent: 27 May 2011 20:14
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] fgdata merge request 91:Animated Jetways
> 
> On Fri, 2011-05-27 at 21:09 +0200, Arnt Karlsen wrote:
> > ..right, then we'll want those fancy gate parking lights too,
> > http://en.wikipedia.org/wiki/Visual_Docking_Guidance_System
> 
> Theoretically that's perfectly possible by piggybacking on my system,
> and we even have the X-plane model required, but I don't feel like
> implementing it. :)
> 

I think we have a marshaller in at least one aircraft model.

Vivian 



--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] SimGear compilation problem with MS VisualStudio10

[Vivian Meazza]

Gene

> 
> On Fri, 27 May 2011, Vivian Meazza wrote:
> 
> >> Any ideas?
> >>
> >
> > I'm still using boost 1.37.0 - it might be worth trying an earlier
> version
> >
> >
> You know that we're using 1.44 currently, right?
> 

I didn't know that - but boost 1.37 still works - I would normally upgrade
when it causes a problem,

Thanks 

Vivian



--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Rating System Redux (was Re:Flightgear-devel Digest, Vol 61, Issue 12)

[Vivian Meazza]

Hal,

 

I can't follow your logic - because there are some aircraft that need a lot
of work, the system shouldn't recognize "advanced features" in other
aircraft that do have them? I also disagree with Stuart that such advanced
features are nice-to-haves and add little to the simulation - why the hell
are we including them then? Do the stores so nicely added to the P-51 add
nothing? On the other hand, the ability to change liveries adds to the
model? Sure doesn't wring my withers, but I suppose the airliner aficionados
(and I'm not one) absolutely must have that.  

 

The P-51 is a superb model already, and at a reasonable frame rate here -
about 75% of my benchmark figure. It would benefit from a tutorial on the
start procedure - but apparently that would win no points either. That seems
to be a missed opportunity too. I suppose the P-51 FDM is accurate - but I
find it not all that pleasant to fly. I would say that you have probably
slightly underrated its score. 

 

In the final analysis - the system currently proposed is only marginally
better than the current "wet finger in the air" method. I think we are
falling a bit short here in our aim to be both objective, and to tell users
more about the available aircraft. In particular, the failure to tell users
that they need a powerful system to use a model, and something about the
difficulty of use, is going to disappoint and or frustrate users.

 

Vivian  

 

 

-Original Message-
From: Hal V. Engel [mailto:hven...@gmail.com] 
Sent: 30 May 2011 23:45
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] Rating System Redux (was Re:Flightgear-devel
Digest, Vol 61, Issue 12)

 

On Monday, May 30, 2011 12:47:41 PM Stuart Buchanan wrote:

> >> I don't have a good answer for the other items. Some are nice-to-haves

> >> that enrich

> >> the simulation experience but don't impact simulation of flight

> >> itself, but others

> >> (such as a co-pilot) are more important for multi-crew aircraft.

> > 

> > Call them all "advanced features". That could be a/the criterion for

> > "advanced production"

> 

> I'm not sure. The "Advanced production" bar is already very high - two 5s

> and two 4s.

> 

> I'm not sure if any aircraft will actually gain it!

 

I would expect that at this point only a few aircraft out there are close to
or are "advanced production" quality. It is a very high standard and any
aircraft that is that far along should really stand out. I would expect that
most of the most advanced current models only need perhaps 1 or 2 points to
get there but adding points when the models are that far along is a lot of
work. But I would be surprised if there were more than a handful of aircraft
that were far enough along to only need 1 or 2 points to become "advanced
production". I think I agree with Stuart that having some things called
"advanced features" does not add much if anything to the system particularly
when we have so many models that are missing many basic things.

 

An example of one that is close but needs more work is the p51d-jsbsim
model. It only needs to improve the external model (add livery support to go
from a 3 to a 4) to get to "production" status and then add one more point
in cockpit, external model or systems would make it "advanced production".

 

Currently it has the following ratings:

 



5

4

3

4



 

The 3D modeling stuff is not my strong suit but I do have new more accurate
3D models for the fuselage and wing (including flaps and aileraons) for the
P-51D that I created a while back. I have also more accurately modeled the
cooling inlet passages and the oil and coolant radiators so that these will
look correct (once textured) when looking into the cooling inlet. I need to
uvmap all of this stuff now and this is where I get stuck as I can't figure
out how to do this so that the resulting uvmaps can be used to create livery
support. Having a nice user friendly uvmap for the fugelage and wings is
more or less nessary to move ahead with libery support I think. 

 

For Systems adding emergency gear release support, oxygen system support,
full cooling system support, VHF radio support, rear warning radar support,
IFF support and some missing electrical system stuff would increase this to
a 5. The 3D models for the controls for all of these systems are already in
the cockpit.

 

One comment about systems. For the P-51 series there are two cooling doors
that are used to control cooling airflow. One for the engine coolant and one
for the oil cooler. JSBSim has support for the coolant door controls but not
for the oil cooler door controls. I have the automatic coolant door stuff
modeled but not the automatic oil cooler stuff because of this. I also need
to add manual overides for these at some point (the controls are in the
cockpit but currently only allow for automatic control). What I am getting
at is that some systems can not be fully modeled because of limitations in
the FDM being used 

Re: [Flightgear-devel] Please insert disk into drive F:

[Vivian Meazza]

> From: Martin Spott [mailto:martin.sp...@mgras.net]
> Sent: 05 June 2011 15:35
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] Please insert disk into drive F:
> 
> Erik Hofman wrote:
> > [...]
> 
> 0) Does it meet the technical requirements for being used in
>FlightGear ?
> 
>   Martin.

Could we please stop hijacking threads?

(and I know Martin wasn't the first offender)


Vivian



--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Please insert disk into drive F:

[Vivian Meazza]

Heiko Schulz wrote

> 
> 
> >> Finally, I found 3 affected global models in fgdata. Martin, can you
> fix
> >> these please (needs to go to the scenery database):
> >> Models/Transport/ICE3middlecar.ac
> >> Models/Transport/ICE3middlecar2.ac
> 
> >  these had been directly committed to CVS by one of those overly
> >clever committers who are known to be ignorant, by tradition, of every
> >general consistency rule. Life could be so easy, if 
> 
> And before someone shouts at me:
> I was the author of the 3d-models- but the mentioned paths had been
> changed after I sent them to Vivian Meazza for including them into CVS.
> Not my fault, especially as I never had any right to directly commit
> things to CVS/GIT.
> 
> Thanks to Thorsten B. for finding the cause of that problem and fixing it.
> 
> 

I will hold my hand up for the D: stuff. There seems to have been a
technical issue with the CVS client I was using at the time using absolute
paths - but now one seems to have noticed up to now. However, I don't and
never have had a F: drive.

And while Martin is making snide remarks - nothing was done without
discussing it with Jon Stockill first. I thought that he was running the
database - obviously he isn't and the discussions were meaningless. Pity no
one has told Jon. 

Vivian





--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Today's Git - MSVC9 build error

[Vivian Meazza]

Today's Git fails to build on MSVC9 with the following error:

"src\Main\main.cxx(624) : error C2017: illegal escape sequence"

this is caused by an errant space at the end line # 624. I have some other
work in train - if no one gets there first, I'll include a fix in that.

Vivian



--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] fgdata merge request 91:Animated Jetways

[Vivian Meazza]

Durk Talsma wrote

> 
> On 05 Jun 2011, at 20:13, Ryan M wrote:
> 
> > On Sun, 2011-06-05 at 16:40 +0200, Durk Talsma wrote:
> >> Hi All,
> >>
> >> After having discussed this issue with Martin privately, we have come
> to the conclusion that it is in the best interest of FlightGear to back
> out parts of this commit, and wait for an improved version. I had accepted
> the merge request, after I had concluded that Martin's original objections
> had been resolved, but that appears not to be the case.
> >
> > Very well. Should I still attempt my proposed amendments?
> >
> 
> Yes please. As indicated, I like the idea, and my impression is that the
> the general consensus is like that. That said, we are uncomfortable with
> some aspects of the current implementation. So, please consider the
> removal temporary until we had ironed out these issue.
> 

Couple of points - did we leave the menu item behind in Environment?

And that doesn't seem to be a very good home for it - it's not weather or
anything like Environment. Would AI be better? (when we restore it).

Vivian 



--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] fgdata merge request 91:Animated Jetways

[Vivian Meazza]

Durk Talsma wrote

> On 06 Jun 2011, at 15:01, Vivian Meazza wrote:
> 
> >
> > Couple of points - did we leave the menu item behind in Environment?
> 
> Are you sure it's still there? I just checked in my local copy and cant
> find a menu item related to the animated jetway system.
> 
> >
> > And that doesn't seem to be a very good home for it - it's not weather
> or
> > anything like Environment. Would AI be better? (when we restore it).
> 
> Yes, I agree.
> 
> (on a side note: I just realize that "Natural Environment" is really what
> we're refering to in the "Environment" menu, whereas "Artificial
> environment" seems to cover what we have in the "AI" menus)
> 

I managed to pull only part of the update late last night - gone now after
another pull.

Thanks

Vivian



--
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] SCR-522 (was Rating System Redux (was Re:Flightgear-devel Digest, Vol 61, Issue 12))

[Vivian Meazza]

Hal wrote

-Original Message-
From: Hal V. Engel [mailto:hven...@gmail.com] 
Sent: 30 May 2011 23:45
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] Rating System Redux (was Re:Flightgear-devel
Digest, Vol 61, Issue 12)

< ... snip ... >

The 3D modeling stuff is not my strong suit but I do have new more accurate
3D models for the fuselage and wing (including flaps and aileraons) for the
P-51D that I created a while back. I have also more accurately modeled the
cooling inlet passages and the oil and coolant radiators so that these will
look correct (once textured) when looking into the cooling inlet. I need to
uvmap all of this stuff now and this is where I get stuck as I can't figure
out how to do this so that the resulting uvmaps can be used to create livery
support. Having a nice user friendly uvmap for the fugelage and wings is
more or less nessary to move ahead with libery support I think. 

For Systems adding emergency gear release support, oxygen system support,
full cooling system support, VHF radio support, rear warning radar support,
IFF support and some missing electrical system stuff would increase this to
a 5. The 3D models for the controls for all of these systems are already in
the cockpit.

One comment about systems. For the P-51 series there are two cooling doors
that are used to control cooling airflow. One for the engine coolant and one
for the oil cooler. JSBSim has support for the coolant door controls but not
for the oil cooler door controls. I have the automatic coolant door stuff
modeled but not the automatic oil cooler stuff because of this. I also need
to add manual overides for these at some point (the controls are in the
cockpit but currently only allow for automatic control). What I am getting
at is that some systems can not be fully modeled because of limitations in
the FDM being used and aircraft authors should rate these as complete
systems if they have modeled everything that is possible with the existing
FDM support. 

< ... snip ...>

I expect you have already seen this - 

ftp://abbeytheatre2.org.uk:2121/flightgear/SCR-522/SCR-522.pdf

Right now I'm busy converting the SCR-522 into its progenitor, the TR1133.
Not that it's hard - externally they are exactly the same bits of kit. I
have found a number of duplicate vertices/bad surfaces however. Based on the
Manual there are some small errors in the interpretion the function of the
T/R/REM, and some of the dimensions. Key. I'll push the TR1133 into git
soon, but as a new item: I will not overwrite any of the SCR-522 stuff.

Vivian   



--
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] SCR-522 (was Rating System Redux (wasRe:Flightgear-devel Digest, Vol 61, Issue 12))

[Vivian Meazza]

Hal,

 

Glad to be able to help. I'm looking forward to your corrected model, then
I'll use it in part or in for the TR1133. As you probably know, the SCR-522
was the TR1133 built initially under a UK contract in the US. The TR1133
transmitter and receiver were reworked by Bendix into a single unit, but the
cockpit control box remained unchanged throughout the life of the equipment
AFAIKS.

 

I now have a working Channel selector interfaced with comm[0] - trivial. Now
for a menu to set the Channel frequencies

 

Vivian

 

-Original Message-
From: Hal V. Engel [mailto:hven...@gmail.com] 
Sent: 07 June 2011 23:24
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] SCR-522 (was Rating System Redux
(wasRe:Flightgear-devel Digest, Vol 61, Issue 12))

 

On Tuesday, June 07, 2011 12:49:34 AM Vivian Meazza wrote:

> I expect you have already seen this - 

> 

> ftp://abbeytheatre2.org.uk:2121/flightgear/SCR-522/SCR-522.pdf

> 

> Right now I'm busy converting the SCR-522 into its progenitor, the TR1133.

> Not that it's hard - externally they are exactly the same bits of kit. I

> have found a number of duplicate vertices/bad surfaces however. Based on

> the Manual there are some small errors in the interpretion the function of

> the T/R/REM, and some of the dimensions. Key. I'll push the TR1133 into

> git soon, but as a new item: I will not overwrite any of the SCR-522

> stuff.

This is great info. I googled the SCR-522 when I was working on it's model
and did not find much on line other than grainy old photos. Because of this
I sized the unit by comparing it to photos of it in place in a P-51 cockpit.
So I knew that it's dimensions were not totally correct and I was not sure
about some other details. 

I mistakenly thought that the switch-locking lever was a dimmer for the
"T-R-REM" indicator lamp. Also I did not know that I had the T-R indicator
lamp function backwards (IE. off when receiving which is what it is on
modern radios - when it should be on when recieving). So these things are
wrong in my model. 

 

Also from the photos I had it was not apparant that the front and back of
the control box had removable covers so the screws are missing as well as
the covers not being propery contured. 

 

My model is also missing the connectors on the bottom of the control box.

 

Then Vivian is able to find a complete manual for the radio which includes
good line drawings for all of the radio components including dimensions.
Having these drawings makes it possible to add other stuff (radio box,
dynamotor, cables and connectors) behind the armor plat in the P-51D (above
the fusealge fuel tank) and have things accurately modeled. So this is very
useful to me as it will make the P-51D model more accurate and detailed.

 

One orher issue is that there are two placards on the side of the radio
control box that in P-51 installations were visible. These are visible in
Figure 17 of the radio manual (page 37) but are only shown edge on. I know
that these are brass plates with red and black backgrounds but I didn't know
what was on these placards and my current texture no content on the
placards. There are no photos/drawings of these particular placards in the
manual. I will do some googling to see if I can find more info about these
placards.

 

Hal

--
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] SCR-522 (was Rating System Redux(wasRe:Flightgear-devel Digest, Vol 61, Issue 12))

[Vivian Meazza]

Hal,

 

I've completed the T/R/REM lock, and the day/night mask - this might be
different to your interpretation of a "dimmer" - AFAIKS its just a plate
with big/small holes which is slid across the lamps. That required a bit of
modification of the existing model here:

 

ftp://abbeytheatre2.org.uk:2121/flightgear/SCR-522/TR1133-Control-Night.jpg

 

All is now pushed into Git. I could add the dialog etc. to the P51D if you
would like.

 

I'm looking forward to the updated models - I think you did an outstanding
job just working from photos. I don't know yet if the TR1133 had a single
box containing the transmitter and receiver, or 2 boxes. In any case, I
think the SCR-522 was also fitted to UK aircraft, at least later in WW2 -
after all that was the purpose of the contract.

 

This is a nice photo of the cockpit control:

 

http://spitfiresite.com/wp-content/uploads/2010/07/02es09_020.jpg

 

Vivian 

 

 

-Original Message-
From: Hal V. Engel [mailto:hven...@gmail.com] 
Sent: 10 June 2011 03:24
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] SCR-522 (was Rating System
Redux(wasRe:Flightgear-devel Digest, Vol 61, Issue 12))

 

On Wednesday, June 08, 2011 01:22:20 AM Vivian Meazza wrote:

> Hal,

> 

> 

> 

> Glad to be able to help. I'm looking forward to your corrected model, then

> I'll use it in part or in for the TR1133. As you probably know, the
SCR-522

> was the TR1133 built initially under a UK contract in the US. The TR1133

> transmitter and receiver were reworked by Bendix into a single unit, but

> the cockpit control box remained unchanged throughout the life of the

> equipment AFAIKS.

> 

> 

> 

> I now have a working Channel selector interfaced with comm[0] - trivial.

> Now for a menu to set the Channel frequencies

> 

> 

> 

> Vivian

 

I am working on the model for the control unit now. It turns out that my
"eyeball" was slightly miscalibrated and the model was too small by perhaps
10% or so. The new version is somewhat bigger (about 1.3 CM longer for
example). But the old version had about the correct proportions. It is now
correctly sized and has the content of the placards as well. I am working on
other details like rivets, connectors and screw heads. The dimmer control
now dimms all of the lights including the TR light.

 

I will also be adding the transmitter/reciever and the dynamotor boxes and
perhaps some connectors so that these can be placed in models where these
are visible like the P-51D. These may not be too useful for your version of
the radio since I will be modeling the Bendix version with a single TR box.
These also may not be visible in your aircraft.

 

When I have the models in place and have updated the P-51D to use them (the
bigger radio requires some changes to the P-51D configuration to get it
properly placed in the cockpit) I will push these into my gitorious
repository and request a merge. I have lots on my plate right now so this
will probably be early next week.

 

One interesting side note for those with an interest in electronics. The
dynamotor has several different output voltages including 28 volts and 300
volts. From my radio backgound (AC6VZ) I know that the 300 volt output is
probably for the power amp stage of the transmitter. I am not too sure how
much power output this unit had but from what I have read air to air range
was several hundred miles. Total power consumption when transmitting is
about 320 watts and 308 watts in recieve so it appears that it's output is
around 10 watts. This is comparible to modern aircraft VHF radios. Of course
modern aircraft radios probably only consume 15 to 20 watts max when
transmitting and perhaps only 1 watt when recieving since they are solid
state and don't have all of the losses in the dynamotor.

 

Hal

 

> 

> 

> 

> -Original Message-

> From: Hal V. Engel [mailto:hven...@gmail.com]

> Sent: 07 June 2011 23:24

> To: flightgear-devel@lists.sourceforge.net

> Subject: Re: [Flightgear-devel] SCR-522 (was Rating System Redux

> (wasRe:Flightgear-devel Digest, Vol 61, Issue 12))

> 

> On Tuesday, June 07, 2011 12:49:34 AM Vivian Meazza wrote:

> > I expect you have already seen this -

> > 

> > 

> > 

> > ftp://abbeytheatre2.org.uk:2121/flightgear/SCR-522/SCR-522.pdf

> > 

> > 

> > 

> > Right now I'm busy converting the SCR-522 into its progenitor, the

> > TR1133.

> > 

> > Not that it's hard - externally they are exactly the same bits of kit. I

> > 

> > have found a number of duplicate vertices/bad surfaces however. Based on

> > 

> > the Manual there are some small errors in the interpretion the function

> > of

> > 

> > the T/R/REM, and some of the dimensions. Key

Re: [Flightgear-devel] SCR-522 (was Rating SystemRedux(wasRe:Flightgear-devel Digest, Vol 61, Issue 12))

[Vivian Meazza]

Hal,

 

I put some comments in-line.

 

Vivian

 

-Original Message-
From: Hal V. Engel [mailto:hven...@gmail.com] 
Sent: 11 June 2011 02:03
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] SCR-522 (was Rating
SystemRedux(wasRe:Flightgear-devel Digest, Vol 61, Issue 12))

 

On Friday, June 10, 2011 08:16:52 AM Vivian Meazza wrote:

> Hal,

 

> I've completed the T/R/REM lock, and the day/night mask - this might be

> different to your interpretation of a "dimmer" - AFAIKS its just a plate

> with big/small holes which is slid across the lamps. That required a bit
of

> modification of the existing model here:

 

>
ftp://abbeytheatre2.org.uk:2121/flightgear/SCR-522/TR1133-Control-Night.jpg

 

I didn't find too much to go on with the day/night mask/dimmer in the docs I


had before. From reading the section about this in the radio manual (page
24) 

it appears that this was probably not infinitely adjustable and that having
a 

large hole and a small hole fits the description in the manual better
although, 

as you wrote, this is a matter of interpretation since the manual is not
explicit about this.

 

On closer reading of p24 and on looking at the diagram on p9 of the manual,
it seems possible that the dimmer mask only covered the Channel indicator
lamps, and not the T/R/REM. light. 

 

> All is now pushed into Git. I could add the dialog etc. to the P51D if you

> would like.

 

The model is very close now. I have improved the textures as well (the box
and 

cover plates now have a crinkle finish). I still need to add the fittings on


the bottom but these are a fairly simple cubes, cylinders and spheres type
of 

things (IE. very east to model) and I should have that done in the next day
or two. 

 

I have adapted your top and light mask to the model so the new version
should work for you as well without many changes to your code. This also
reduces the number of vertices/edges so the model is a little smaller than
it was. 

 

Also the cover plates were interchangeable according to the manual. One of
these plates has the placards and the other has mounting holes and depending
on the installation these covers were interchanged so that the one without
placards could be attached to the mounting surface/bracket in the aircraft.
It appears that your installation has it mounted with what is the mounting
cover visible in the cockpit which is not correct. I have put the placards
on both side covers so that it can be mounted either way with the placards
still visible. This works fine in the P-51D and it should work in your Spit
as well.

 

Don't bother with implementing this in the P-51D since I can look at (and 

steal - is that OK?) your code. I had a look at your stuff and it did not
appear to be a big deal to port this to the SCR-522 and the P-51D. I will
try to generalize this so that it can be used by any aircraft since it could
be useful to those working on other WWII aircraft like the P-47, P-38, P-39,
P-40, Corsair, F6F, B-17 and perhaps a dozen others.

 

Please take anything you want. Did you notice that the binding for F12 was
changed to bring up the new menu? I would really like to use the new dialog
in the same way as the default one rather than in the aircraft-specific
menu, but right now can't figure out how to do that.

 

I think we might end up with 2 near-identical entries in
Aircraft/Instruments-3d. I suppose that's OK, since UK aircraft would expect
the TR1133, and the US the SCR-522. Hmm, what was it known as in RAF P51s?


 

> I'm looking forward to the updated models - I think you did an outstanding

> job just working from photos. I don't know yet if the TR1133 had a single

> box containing the transmitter and receiver, or 2 boxes. In any case, I

> think the SCR-522 was also fitted to UK aircraft, at least later in WW2 -

> after all that was the purpose of the contract.

 

The radios in US and Britsh aircraft were standardized very early in the 

war. There was lots of cooperation between the US and the UK particularly on


electronics (communication radios and radar) and this started before the US 

was officially at war. Reading the history on these VHF radios it appears
that 

the initial prototypes where Britsh and that these were improved and made
into 

production items by companies in the US primarily Bendix.

 

The BC-602-A control box appears to have been used for all 4 channel VHF 

radios through out the war (and into the Korean war at least in the P-51D's)
and it was basically unchanged from what it looked like as a prototype. 

 

I now discover that the boxes were the same - only the internals differed.
However, I haven't yet discovered where the boxes were fitted.

 

> This is a nice photo of the cockpit control:

>  

> http://spitfiresite.com/wp-content/uploads/2010/07/02es09_020.jpg

 

There is at least one differ

Re: [Flightgear-devel] SCR-522 (was RatingSystemRedux(wasRe:Flightgear-devel Digest, Vol 61, Issue 12))

[Vivian Meazza]

Hal,

 

More comments inline. Looking forward to getting this into Git so I can
progress a bit more.

 

Vivian

 

 

> 

> On closer reading of p24 and on looking at the diagram on p9 of the
manual,

> it seems possible that the dimmer mask only covered the Channel indicator

> lamps, and not the T/R/REM. light.

 

What specifically on page 9 are you seeing?

 

On page 9 I see what I think is the mask in place over  the channel lights
with the small hole over the channel visible - compare and contrast that
with the photos that we have found with the in the day position. Page 9 also
shows the T/R/REM. light unmasked. The words on page 24 also imply this to
be the case. But see my comments lower down

 

I am not sure I agree but I can't say for sure. All of the lamps are in line
with each other so they could easily use the same types of masks and a
common lever for dimming all five lamps. In addition, not dimming the
T/R/REM lamp would not make operational sense since they would have been
very concerned about night blindness and the lamp is white (see next
paragraph) which is not a good thing from a night vision point of view. Also
the 1952 USAF F-51D/K/H manual seems to imply that all of the lamps are
dimmed by the lever although it does not say this explicity. On the other
hand the Aug. 1945 USAAF P-51D/K manual seems to imply that the dimmer mask
only affects the channel lights but again it is not explicit about this. So
I don't know. Perhaps the Spit pilot manuals can shed some light on this? 

 

Not quite in line - but yes it would not have been difficult to have
extended the mask to cover all lamps - and I agree that it would be logical
for this to be the case.

 

Also something that I had missed from the 1952 manual is that the T/R/REM
lamp is white and the others are green. In most photos I have seen the lamps
all appear to be a greenish blue color, this is clearly the case in the ebay
auction photos, but perhaps this is because they are not lit in these
photos. A yellowish lamp under a blueish lens would glow a green color when
lit while still appearling blue when not lit. Also the photo at this link
shows the channel lamps as a green blue and the T/R/REM lamp as white. 

 

http://www.worthpoint.com/worthopedia/radio-control-box-bc-602-part-scr-522-
76082646

 

Too much info - does that photo show the dimmer mask in the down position?
I think so, it looks as if I am wrong about the hole theory - the blue is
transparent mask over - what?  Perhaps a more transparent blue mask? The T/R
lamp is not masked.  But I'm not sure that we want to introduce a
transparency in our model - bad for framerate. We can easily fix things to
look right without transparency.

 

I will change the colors of the lamps to match the documentation. But this
is another case where the evidence is contradictory. What colors should
these be when lit and off? I will make my best guess and if some evidence
comes along that my guess is incorrect it will get fixed.

 

Green is a very usual colour for channel lights - and red/orange for T (but
we know that the SCR-522 worked in reverse). But all photos show the unlit
lamps/mask to be blue. 

 

snip

> 

> Please take anything you want. Did you notice that the binding for F12 was

> changed to bring up the new menu? I would really like to use the new
dialog

> in the same way as the default one rather than in the aircraft-specific

> menu, but right now can't figure out how to do that.

 

I has a new high level menu for the VHF radio stubbed in (IE. the menu does
not do anything yet). So I have some thing working and when I have a chance
to look at your stuff I will try to generalize it so that it has it's own
high level menu.

 

> I think we might end up with 2 near-identical entries in

> Aircraft/Instruments-3d. I suppose that's OK, since UK aircraft would

> expect the TR1133, and the US the SCR-522. Hmm, what was it known as in

> RAF P51s?

 

I think this may be the case and it might make sense to consolidate these
into one set of models and code. The names used internally by the aircraft
models does not really matter since to the user these are the same units.
They look and function in exactly the same way.

 

Yup - I really only started the TR1133 so that I could avoid overwriting
your stuff. I'll leave this one until we have finished.

 

snip 

> 

> I now discover that the boxes were the same - only the internals differed.

> However, I haven't yet discovered where the boxes were fitted.

 

I found this online:

 

http://target4today.co.uk/forum/viewtopic.php?showtopic=643
 &mode=&show=20&page=3

 

Very useful info. Not sure about the comment on the Spitfire prop weight -
my info shows the DeHavilland 3 bladed metal prop/hub at 350 lbs - which
would have been right for the BoF, while the later constant speed propeller
would have weighed in at 500lbs, but these were not fitte

Re: [Flightgear-devel] "Pro Flight Simulator"

[Vivian Meazza]

Michael,

 

What do you suggest be done? And perhaps you could do something?

 

Otherwise we do nothing, and it's caveat emptor. 

 

Vivian

 

 

-Original Message-
From: Michael Sgier [mailto:scrat_h...@yahoo.com] 
Sent: 12 June 2011 10:58
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] "Pro Flight Simulator"

 


http://www.androidzoom.com/android_games/cards_and_casino/flight-simulation_
xcuh.html

how long should we tolerate such...


 

 

--
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] Airport Textures (Again)

[Vivian Meazza]

Can we please have the old airport textures back: the new ones wreck some
very fine airports. Here's a small sample of Gatwick/EGKK. It's like this
all over and it's spoiling someone's very good work:

ftp://abbeytheatre2.org.uk:2121/flightgear/Terrain/EGKK-texture.jpg

Yes - of course, I can do that locally, but can we really have this ugliness
in our flightsim?

Vivian




--
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] Airport Textures (Again)

[Vivian Meazza]

Syd wrote
> 
> I'll have to agree here . There's also some pretty gaudy terrain
> textures too , whatever happened to a general vote on commits ?
> 
> 
> On Sun, Jun 12, 2011 at 11:39 AM, Vivian Meazza
>  wrote:
> > Can we please have the old airport textures back: the new ones wreck
> some
> > very fine airports. Here's a small sample of Gatwick/EGKK. It's like
> this
> > all over and it's spoiling someone's very good work:
> >
> > ftp://abbeytheatre2.org.uk:2121/flightgear/Terrain/EGKK-texture.jpg
> >
> > Yes - of course, I can do that locally, but can we really have this
> ugliness
> > in our flightsim?

In 2003 this was committed:
 
"Remove the broken yellow lines around the taxiways.  They're rare in real
life, and look awful in FlightGear, since we cannot really align taxiways
yet anyway."

Now we have put back, not broken yellow lines, but solid ones, which look
even worse. We still can't align taxiways correctly, and they still don't
look all that good without the edge lines, but unless someone comes up with
a cogent argument, I intend to revert the new taxiway textures.

Vivian



--
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] Airport Textures (Again)

[Vivian Meazza]

I wrote:

> Syd wrote
> >
> > I'll have to agree here . There's also some pretty gaudy terrain
> > textures too , whatever happened to a general vote on commits ?
> >
> >
> > On Sun, Jun 12, 2011 at 11:39 AM, Vivian Meazza
> >  wrote:
> > > Can we please have the old airport textures back: the new ones wreck
> > some
> > > very fine airports. Here's a small sample of Gatwick/EGKK. It's like
> > this
> > > all over and it's spoiling someone's very good work:
> > >
> > > ftp://abbeytheatre2.org.uk:2121/flightgear/Terrain/EGKK-texture.jpg
> > >
> > > Yes - of course, I can do that locally, but can we really have this
> > ugliness
> > > in our flightsim?
> 
> In 2003 this was committed:
> 
> "Remove the broken yellow lines around the taxiways.  They're rare in real
> life, and look awful in FlightGear, since we cannot really align taxiways
> yet anyway."
> 
> Now we have put back, not broken yellow lines, but solid ones, which look
> even worse. We still can't align taxiways correctly, and they still don't
> look all that good without the edge lines, but unless someone comes up
> with
> a cogent argument, I intend to revert the new taxiway textures.
> 

Or, I could do the job properly and remove the offending edge lines. I'll
see what I can come up with.

Oh - and Syd, which crop texture is offending you in particular?

Vivian



--
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] Airport Textures (Again)

[Vivian Meazza]

I wrote:

> I wrote:
> 
> > Syd wrote
> > >
> > > I'll have to agree here . There's also some pretty gaudy terrain
> > > textures too , whatever happened to a general vote on commits ?
> > >
> > >
> > > On Sun, Jun 12, 2011 at 11:39 AM, Vivian Meazza
> > >  wrote:
> > > > Can we please have the old airport textures back: the new ones wreck
> > > some
> > > > very fine airports. Here's a small sample of Gatwick/EGKK. It's like
> > > this
> > > > all over and it's spoiling someone's very good work:
> > > >
> > > > ftp://abbeytheatre2.org.uk:2121/flightgear/Terrain/EGKK-texture.jpg
> > > >
> > > > Yes - of course, I can do that locally, but can we really have this
> > > ugliness
> > > > in our flightsim?
> >
> > In 2003 this was committed:
> >
> > "Remove the broken yellow lines around the taxiways.  They're rare in
> real
> > life, and look awful in FlightGear, since we cannot really align
> taxiways
> > yet anyway."
> >
> > Now we have put back, not broken yellow lines, but solid ones, which
> look
> > even worse. We still can't align taxiways correctly, and they still
> don't
> > look all that good without the edge lines, but unless someone comes up
> > with
> > a cogent argument, I intend to revert the new taxiway textures.
> >
> 
> Or, I could do the job properly and remove the offending edge lines. I'll
> see what I can come up with.
> 
> Oh - and Syd, which crop texture is offending you in particular?
> 

OK - I pushed some new concrete taxiway texture into Git. It isn't quite as
pretty as the previous, but you can't see the join, well hardly :-).  That
will do for now. Perhaps I can add some dirt without exposing the joins -
I'll try that in due course 



--
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] Rating System Redux

[Vivian Meazza]

Gijs,

 

Some comments inline.

 

Vivian

 

-Original Message-
From: Gijs de Rooy [mailto:gijsr...@hotmail.com] 
Sent: 13 June 2011 13:17
To: FlightGear Development list
Subject: Re: [Flightgear-devel] Rating System Redux

 

Hi all,
 
just pushed ratings for my vehicles to Git (wow, didn't know I had that many
(uninished) vehicles! 
This year I didn't start new aircraft IIRC, I'm now finishing up my existing
ones instead, as I should
have done in the past years...). Anyway, I came across some issues with the
rating system:
 

1.  Certain vehicles do not have a cockpit. For example my jetman, which
is basically a man
hanging under a pair of wings equipped with jets. How would one give this
man a cockpit-
rating?! Maybe cockpit should mean "instruments and controls"? In that case
I can give this
man a rating: the ignition switch and parachute handle are missing from the
model. 

For now I gave him a "3", but I'd like to hear opinions and see a note being
added to the wiki
on how to deal with such issues. It isn't as easy as "If your aircraft does
not have a given system,
ignore it for the purposes of rating" ;)

If the model has no cockpit (correctly) then it gets a 5 (totally
realistic). If it's missing a couple of switches, then that's a 4

2.  I think the alpha-range is rather big, compared to the others. There
is an awfull lot of difference
between a total=0 aircraft and a total=8 (eg. Model=3, FDM=3, Cockpit=0,
Systems=2). I 
don't care if my vehicles end up low in the completness-rating (I consider
my best aircraft 
early production) but I do feel "offset" to see my aircraft end up next to
an empty hull. Adding
in a 0-4 rating would be nice IMO; we can call that "pre alpha".

 

Just how many systems are there - this must be a 4 as well?

 So that would become 3 + 3 + 4 + 4 = 14 = early production. Good enough for
me :-)


Just some Monday afternoon ideas :)
 
Cheers,
Gijs

--
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] Rating System Redux

[Vivian Meazza]

Gijs wrote:

 

> Vivian wrote:
>
> Just how many systems are there - this must be a 4 as well?
> So that would become 3 + 3 + 4 + 4 = 14 = early production. Good enough
for me :-)

My 2nd point wasn't about the Jetman ;)

But yeah, I do think the Cockpit might be a 4 rather than a 5 then. Will
wait for some more
opinions.

 

Now how was I meant to guess that :-)?

--
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] Airport Textures (Again)

[Vivian Meazza]

Yves wrote

> 
> Am 13.06.11 18:33, schrieb syd adams:
> >> Oh - and Syd, which crop texture is offending you in particular?
> >>
> >> Vivian
> >
> > not the crop textures ... the forest1a , b and c . I dont remember who
> > did the previous terrain textures , but he/they did a great job ...
> > especially the look of irregular terrain type as it faded in the
> > distance. Now we get a fuzzy carpet look :). I vaguely recall there
> > was a reason for this new one ... maybe to do with more wasteful
> > shaders ;) .
> > I guess my biggest beef is the lack of any kind of
> > control/organization , and the fact that after a few requests , I
> > still can't update my own git aircraft  (and now not interested
> > anymore).
> 
> Hi Syd
> 
> Your biggest beef is the lack of any kind of absence in discussion about
> this textures and realted shaders, and help to improve them.
> 
> So please stop to blame my work here in the list when you're not
> interested in any kind of contribution anymore.
> 

Of course, it might just be the damned translation engines again but ...
Yves - no one's work is immune from criticism: not yours or mine. Syd has
contributed much to this project over the years. His opinion is as valid (or
invalid) as anyone else's.

Let's all try to pull in the same direction.

Vivian



--
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] Airport Textures (Again)

[Vivian Meazza]

Alexis wrote

> -Original Message-
> From: Citronnier - Alexis Bory [mailto:alexis.b...@gmail.com]
> Sent: 14 June 2011 18:05
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] Airport Textures (Again)
> 
> Le 12/06/2011 19:39, Vivian Meazza a écrit :
> >  Can we please have the old airport textures back: the new ones wreck
> >  some very fine airports. Here's a small sample of Gatwick/EGKK. It's
> >  like this all over and it's spoiling someone's very good work:
> >
> >  ftp://abbeytheatre2.org.uk:2121/flightgear/Terrain/EGKK-texture.jpg
> >
> >  Yes - of course, I can do that locally, but can we really have this
> >  ugliness in our flightsim?
> >
> >  Vivian
> >
> 
> Hi all,
> 
> I also find the previous texture better,  me miss the dark asphalt, and
> the side yellow lines spoils a lot of discrete tricks we used to solve
> some airport layout problems.
> 
> I vote for reverting to the previous textures.
> 

OK - I've removed the yellow edge lines from the asphalt and concrete
taxiways. In Git now - I hope that's solved the problem. 

Vivian



--
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] Heads up: scenery download / built-in terrasync

[Vivian Meazza]

ThorstenBv  wrote

> 
> Hi,
> 
> the final GUI bits for a new feature are now in fgdata - the last
> feature addition for the 2.4 release from my part... You can
> download/update scenery directly from FlightGear now (main menu:
> Environment => Scenery). Credit for the idea goes to James - bugs are
> mine ;-).
> 
> It provides built-in terrasync support - with some advantages:
> 
> * Configuration requires a scenery target directory only (your
> "terrasync" directory) and a checkbox to enable. For now, you'll also
> need to provide the terrasync directory as part of your --fg-scenery
> paths (otherwise you won't see downloaded scenery). Maybe we can add the
> directory to the search path internally some time, simplifying things
> even more. Should help anyway (especially new users) in obtaining world
> scenery. Not quite as simple as loading scenery with Google Earth yet -
> but closer...
> Before someone asks: the scenery server address is displayed in the GUI,
> but editing is disabled. Is there any reason (right now), why users
> would want to change? (You could still change using preferences.xml /
> property browser though).
> 
> * You can enable/disable scenery download any time using the menu. When
> you notice mid-flight that scenery is missing, just enable the download
> checkbox and wait a bit (depending on your connection speed ;-) ).
> 
> * There is also a (still experimental) option to refresh scenery tiles
> once their update is complete. You could "warp" into a new region,
> initially see ocean only (default replacement for missing scenery) and
> eventually see the ocean tiles being replaced by actual scenery. That's
> still experimental though, the update logic requires improvement. Looks
> weird when scenery tiles are removed when the a/c is just parked/rolling
> on them (old scenery disappears for a second before the "fresh" one
> reappears). Also bad on final approach... And the a/c position and
> altitude of clouds may need to be adapted when scenery altitude has
> changed - which is a problem when ocean (sea level) is replaced by
> actual scenery (mountains...). Usually ok to enable the feature
> mid-flight. Otherwise, there is also a manual "refresh" button, so you
> could choose yourself at what time to replace ocean/missing scenery.
> 
> The feature reuses the terrasync sources and relies on a subversion
> client. Either using built-in subversion (when "libsvn" is installed,
> which is recommended). Otherwise, fgfs tries calling an external utility
> ("svn") for downloads. All the same as with original terrasync.
> The built-in svn support is enabled for automake right now (use
> "--with_libsvn=no" to disable). It's off by default for cmake builds (we
> could change that, use "ENABLE_LIBSVN" to enable for now). The cmake
> build isn't really well tested yet - except that Hudson seems happy for
> all targets. And as mentioned, I'd need help with cmake if it wasn't
> working properly. And it'd also be good to get Hudson to build the
> Windows/Mac binaries with built-in svn support (seems to do that for
> Linux/automake already).
> 
> As usual, report any (new) issues. If you don't like the feature, keep
> the checkbox disabled and the whole thing shouldn't bother you. You can
> keep using manual downloads or the separate terrasync utility as before
> (which lives on), of course.
> 
> cheers,
> Thorsten
> 
> PS: Yes, a complete update (sg+fg+fgdata) is required for things to
> work.

Fred - should this work with MSVC9? It compiles and runs, but I get this
error:

"Cannot start scenery download. Rsync scenery server is undefined."

The server input in the menu item is blank, and does not accept any input

Vivian 



--
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] Heads up: scenery download / built-in terrasync

[Vivian Meazza]

Fred wrote
Fred wrote

 
> > Please pull latest SimGear
> 
> And Flightgear too
> 

Well, I thought I had - otherwise I wouldn't have re-compiled and run it,
would I? And it does compile and run - even provides error messages.

Vivian



--
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] Heads up: scenery download / built-in terrasync

[Vivian Meazza]

Fred

> -Original Message-
> 
> It was not a reproach. I just committed fixes at the time I sent those
> messages
> 
> -Fred
> 
> - "Vivian Meazza" a écrit :
> 
> > Fred wrote
> > Fred wrote
> >
> >
> > > > Please pull latest SimGear
> > >
> > > And Flightgear too
> > >
> >
> > Well, I thought I had - otherwise I wouldn't have re-compiled and run
> > it,
> > would I? And it does compile and run - even provides error messages.
> 

Hmmm - pulled, compiles and built.

But when it I try to use it I get the following errors:

http://pastebin.com/3c6J4D4r

I'm probably missing something obvious - any clues?

This was NOT a good time to introduce a whole new idea, just before a
release. And I can't see any real advantage over Fred's implementation in
FGRun, which I have used for years. In any case, you have to decide a priori
to use Terrasync - you need to specify the terrasync scenery directory 

This is more or less consistent with Gene's, Csaba's and Ron's view - I'm
happy to set this all up, and more, in a separate GUI. 

Vivian




--
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] Heads up: scenery download / built-in

[Vivian Meazza]

Martin Spott wrote

> -Original Message-
> From: [mailto:martin.sp...@mgras.net]
> Sent: 15 June 2011 18:36
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] Heads up: scenery download / built-in
> 
> "Vivian Meazza" wrote:
> 
> > This was NOT a good time to introduce a whole new idea, just before a
> > release.
> 
>   http://wiki.flightgear.org/Release_Plan#Detailed_Time_Schedule
> 
> June 17th is declared as being the feature freeze day. Thus, as long as
> they don't commit a pile of crap to the repository, why should people
> refrain from adding new features during the regular development cycle ?
> 
> > [...] And I can't see any real advantage over Fred's implementation in
> > FGRun, which I have used for years.
> 
> Some people _do_ see a real advantage.

And all I said was that I don't. Let others speak for themselves.

> > [...] In any case, you have to decide a priori
> > to use Terrasync - you need to specify the terrasync scenery directory
> 
> Indeed. I suspect that clever users of this feature are going to
> hardwire the TerraSync scenery directory via some command line alias,
> preferences file, ~/.fgfsrc or whatever, like they do for other custom
> preferences.  It's up to you to do the same.

And less clever users, which is most of the people out there, won't. I
include myself in that category, since I have failed to make it work so far.
I sometimes wonder if we really expect the average user to poke around in
preferences.xml? But then, we have FGRun that does most of that for us.
 
> > This is more or less consistent with Gene's, Csaba's and Ron's view -
> I'm
> > happy to set this all up, and more, in a separate GUI.
> 
> "This" is not consistent with Gene's, Csaba's and Ron's view. If you
> read carefully, then you'll realize that these three guys have
> primarily expressed their opinion on wether to have the GUI inside the
> visual system or not.
> 

"This" is indeed more or less consistent with those opinions. Csaba says:
"For example, all the GUI stuff should be thrown out and left to a
launcher/control console application." Gene says: "All the functionality in
the GUI could be provided in a stand-alone tool that talked to the
simulator." Ron says that he supports Csaba. I said: "I'm
happy to set this all up, and more, in a separate GUI." How is my view
inconsistent? 

Vivian 



--
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] Heads up: scenery download / built-in

[Vivian Meazza]

Gene

> 
> On Wed, 15 Jun 2011, Vivian Meazza wrote:
> 
> >>
> >
> > "This" is indeed more or less consistent with those opinions. Csaba
> says:
> > "For example, all the GUI stuff should be thrown out and left to a
> > launcher/control console application." Gene says: "All the functionality
> in
> > the GUI could be provided in a stand-alone tool that talked to the
> > simulator." Ron says that he supports Csaba. I said: "I'm
> > happy to set this all up, and more, in a separate GUI." How is my view
> > inconsistent?
> >
> 
> The one wrench in the works is aircraft (and their systems) that add
> entries to the GUI menu items...
> 

If you can generate a better way, or even an alternate way - I'll look at
it. Until then you're stuck with it.

Vivian



--
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] Heads up: scenery download / built-in

[Vivian Meazza]

ThorstenB wrote:

 
... snip ...

> 
> On 15.06.2011 23:30, Vivian Meazza wrote:
>  > And less clever users, which is most of the people out there, won't. I
>  > include myself in that category, since I have failed to make it work
>  > so far.
>  > I sometimes wonder if we really expect the average user to poke
>  > around in preferences.xml? But then, we have FGRun that does most of
>  > that for us.
> 
> There should be no need to edit anything in preferences.xml. You should
> be able to enter the directory in the GUI (yes, I know, no directory
> dialog). Or you could also provide it via a new command-line option
> (--terrasync-dir). And it's preserved across sessions. So you only need
> to provide/edit it once. I had responded to your email yesterday in
> private, hinting that you probably somehow managed an incomplete fgdata
> pull (which you later confirmed). Maybe something is still broken -
> maybe with my code or still on your system. Or maybe I forgot to push
> something.

 Yes - _I_ know that your code does not require anything done to
preferences.xml by the user. And, as I said, the average user should not be
required to do so.

> So, I am really sorry, Vivian, that you were still unable to make the
> system work for you - on day 2 (though it seems people only started
> trying to use it _today_).

I'm reasonably sure it's something here. But the latest Hudson build #331
doesn't work here either, with the same error messages as my local build.
The trouble is, I have no idea how to fix it.

> But this and other posts today show our general FG mailing list
> tendency: being negative. It's the almost natural response to any
> change. Oh crap! Doesn't work! Don't like it... I've spent _loads_ of
> time into FG in recent months. I have worked the bug tracker almost
> daily. I have fixed countless bugs other people have introduced - _some_
> even hidden in absolutely crappy code (so much on the "design" issue). I
> have searched and fixed memory leaks and investigated performance
> issues. I've fixed loads of issues affecting systems that I personally
> never use. So, if anything wasn't working with my _own_ addition now -
> only in GIT for two days, remember - I think it should've been more than
> obvious that I'd be absolutely willing to explain/test/resolve things -
> and help anyone who was really interested. And to make it work as
> expected: to provide an easier solution in accessing scenery (read the
> forums, if you want to know how users do get along with existing
> terrasync). But that's not how FG works. It's "normal" that any slight
> malfunction is immediately criticized as hell. No attempts in being
> positive, trying to encourage / motivate other people in improving their
> work - and to keep them working on FG. When something isn't working,
> start complaining and being negative. Just look at this list's recent
> history.

Yes, you have done very well for FG, and I'm sure everyone is very grateful,
even if they don't say it. I know I am. 

But, if you suddenly thrust something into FG which hasn't been announced or
trailed in any way, for which no clear need has been established, and which
apparently doesn't work, at least for some (or possibly only me), you will
get a majority of seemingly negative comments. That's just inevitable - for
those who are happy won't say anything and those that are unhappy will be
vociferous. At the end of the day, they are just other peoples' opinions:
you can either accept them or ignore them.

FWIW - on the few occasions in the past when I made major contributions to
FG I ensured that they were tested on both Linux and Windows by others
before they the ever saw the light of day. I'm always ready to test stuff
for you or anyone else. This is actually what I was trying to do on this
occasion.
 
> So, you're all hoping for a better FG. A large redesign, so we can make
> use of multi-core systems, can even distribute parts across multiple
> machines. Can separate the GUI. Get Nasal outside the main simulation
> loop. Well, so do I. But I'm becoming more and more convinced, that this
> indeed is _not_ going to happen. No, not because of that "new" library
> and "such tendencies" (while in fact that library is much better
> prepared to be driven by HLA or something similar than most other
> parts). No, we're very likely to not get any of this since we're
> absolutely unable to motivate - or at least keep people motivated on
> working on our project. That's a major issue we have. Everyone who
> spends time is "welcomed" by negative comments - and surprisingly many
> leave. And I'm

Re: [Flightgear-devel] Heads up: scenery download / built-in

[Vivian Meazza]

ThorstenB wrote:

... snip ...
> 
> So, I am really sorry, Vivian, that you were still unable to make the
> system work for you - on day 2 (though it seems people only started
> trying to use it _today_).
> 
... snip ...

Getting back to the original purpose ... it's worse than I thought. Using
Hudson Build #331 (the latest AFAIKS), Target Directory seems to stick, but
I have made it run just once. I will file a proper bug report.

Vivian



--
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] Heads up: scenery download / built-in

[Vivian Meazza]

Erik

> 
> On Fri, 2011-06-17 at 10:55 +0300, thorsten.i.r...@jyu.fi wrote:
> > At this point, it made a lot of sense to code in Nasal, if only for the
> > simple reason that I couldn't know if it would ever included into the
> base
> > package or not.
> 
> As an addition it also helped to develop good insight in efficient Nasal
> programming which might prove to be very useful in the future.
> 

I'm not sure that 'efficient Nasal' isn't an oxymoron :-)

I would never claim to have written efficient, or even good or clever Nasal,
but here are some simple heuristics:

Avoid for and while loops - if you must have them, keep the number of
iterations low, otherwise you will kill the frame rate.

It is better to do a little work every frame rather than a lot of work in
intermittent frames, otherwise you will introduce jitter. 

Avoid writing too many lines, otherwise the evil god Garbage Collector will
bite you.

Avoid writing Nasal. Now we are compiling snapshots of the source code
nightly, where code is generally applicable it should, if at all possible,
be written in c++.

Here is the long version:

http://wiki.flightgear.org/index.php/Nasal_scripting_language

Perhaps Melchior will provide better advice.


Vivian 





--
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] SCR-522

[Vivian Meazza]

Hal,

 

Since the dialog seems to be fundamentally broken, and in view of the freeze
that has been declared on fgdata, I won't be merging this immediately. I'll
see if I can fix up the Nasal errors, and then review the situation.

 

Vivian

 

-Original Message-
From: V. Engel [mailto:hven...@gmail.com] 
Sent: 18 June 2011 05:50
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] SCR-522

 

On Friday, June 17, 2011 11:33:29 AM Hal V. Engel wrote:

> On Sunday, June 12, 2011 03:07:25 AM Vivian Meazza wrote:

> > Hal,

> 

snip

 

> I grabbed your code off of GIT and did some minor mods to it mostly to

> point things at the right locations. The menu XML is currently

> unmodified. I am trying to get it to work but I am getting loadxml errors

> from Nasal when I hit the

> 

> var radio = gui.Dialog.new("dialog",

> "Aircraft/Instruments-3d/SCR-522C/Dialogs/radios.xml")

> 

> line of code. The error message says:

> 

> loadxml: reading '' denied (unauthorized

> access) Nasal runtime error: Dialog class: XML dialog mush have 

 

>From mfranz on the forums I learned that this should not be happening and
that it could be an issue with the "loadxml" fgcommand when using
--fg-aircraft. My fg-aircraft path is showing up in the log in the
IORules/READ: line when I have --log-level=info set. I am running GIT from
about 3 weeks ago.

 

> 

> > That's all looking good. Can we get it into Git soon?

snip

 

I now have everything except the menu working. The 3D model is complete
although the texturing of the fittings on the bottom of the unit is crude
(but these are not visible in most installations). All of the controls have
hot spots and the radio control unit can be fully manipluated with a mouse.
Everything appears to be working correctly including how the ptt works with
a remote ptt switch. All of the lights are functional and so is the dimming
mask.

 

I will be pushing this to my gitorious fgdata copy tomorrow along with some
other P-51D updates after I make sure that everything is tested again. WIth
the freeze I don't know if I will be able to get this into GIT but the radio
has been in GIT for some time so perhaps I can. Once it is in my gitoriious
copy of fgdata you can grab it for your Spitfire work. In the mean time
perhaps some one here might know how to get the radio menu working or
perhaps have some ideas about things that can be tried.

 

Hal 

 

--
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] Nasal updating properties in the menu

[Vivian Meazza]

Hal,

 

Works nicely here - I've just pushed an update into the TR1133.nas file 

 

This is the line:

 

gui.menuBind("radio", "TR1133.radio_dlg.open()");

 

You should be able to adapt that to the SC-522

 

Vivian

 

-Original Message-
From: Hal V. Engel [mailto:hven...@gmail.com] 
Sent: 20 June 2011 00:55
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] Nasal updating properties in the menu

 

On Sunday, June 19, 2011 02:15:54 PM Ron Jensen wrote:

> On Sunday 19 June 2011 15:04:11 Hal V. Engel wrote:

> > I need to over ride one of the default menu items so that I can use a

> > custom menu. After some effort I have figured out what needs to be

> > changed

> > 

> > in the property tree. The code looks like this:

> > # Disable the menu item "Equipment > radio" so we use our own gui.

> > 

> > gui.menuEnable("radio",0);

> > 

> > # override default radio menu

> > setprop("sim/bindings/menu/binding[35]/dialog-name", "SCR-522C-radio");

> > setprop("sim/menubar/default/menu[5]/item[3]/binding/dialog-name",

> > 

> > "SCR-522C-radio");

> > 

> > setprop("sim/menubar/default/menu[5]/item[3"]/name", "SCR-522C-radio");

> > 

> > gui.menuEnable("SCR-522C-radio",1);

> > 

> > And this is working. But I am concerned that if the menus should be

> > changed (IE. items added or removed) that this would no longer be
correct

> > and the code will start failing. Is that true? If so ithere a better

> > way to do this sort of thing?

> > 

> > Hal

> 

>
http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg30208

> .html gui.menuBind("radio", "dialogs.Radio.open()");

 

Thanks I knew I saw something about this on the list but I coundn't find the
emails that covered it. When I try to use it it fails when I click on the
menu item. 

 

Here is my code:

 

var radio = gui.Dialog.new("sim/gui/dialogs/SCR-522C/dialog",

"Aircraft/Instruments-3d/SCR-522C/Dialogs/radios.xml");

gui.menuBind("radio", "dialogs.radio.open()");

 

When I select Equipment --> Radios I get the following error message in the
console:

 

Nasal runtime error: undefined sysbol: dialogs at
/sim/bindings/menu/bindings[35], line 1

 

I must be doing something wrong but I don't see what it is. Can anyone here
spot my error?

 

Hal

 

 

> 

>
---

> --- 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

 

--
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] Heads up: scenery download / built-in

[Vivian Meazza]

I wrote:

> 
> ThorstenB wrote:
> 
> ... snip ...
> >
> > So, I am really sorry, Vivian, that you were still unable to make the
> > system work for you - on day 2 (though it seems people only started
> > trying to use it _today_).
> >
> ... snip ...
> 
> Getting back to the original purpose ... it's worse than I thought. Using
> Hudson Build #331 (the latest AFAIKS), Target Directory seems to stick,
> but
> I have made it run just once. I will file a proper bug report.
> 

I have now been working with Terrasync/Built in scenery download for over a
week now. I though I might share with you some observations using Win XP and
MSVC9

The bug which was stopping the built-in download running here was trivial -
once we found it: a space in a directory name. Replaced with an underscore
and it worked right out of the tin. Not quite - only the external mode was
available. That turned out to be caused by a non-updated config.h file.
Thanks to Fred for his help and guidance to solve that one.

In doing this I noticed that both the built in and external variants seem to
be functionally similar. I can't even work out how or why the external
variant works - but it does. FG finds, starts, and stops the external SVN
program. Either ThostenB has been very clever, or it's just serendipity
here. I hope it's the former.

I decided to revert my local build to external only, and then compare
Terrasync started from FGRun with the internal (using Hudson's nightly
build) and external variants (using my build). Using the Spitfire4b at
Gatwick I discovered:

1. With no download the framerate was 42 with the local build and 33 with
the Hudson build. I suspect that is caused by different compiler options.

2. With scenery download running each option costs about 10 fps.

3. The Terrasync/FGRun scenery pre-fetch option works well, and is useful.

4. It is handy to be able to switch off/on scenery download at runtime, but
here you only get about 5 of the 10 fps back. I see that once started the
svn program remains loaded: this might be the cause.

5. The automatic refresh works well. There is an occasional grey-out.
Disconcerting at first, but actually not a problem. This is a major
advantage over Terrasync

5. To use the built-in option requires 2 additional and quite large
dependencies which will need updating etc from time to time. For those of us
that build FG this is a bit of a pain. 

6. Both the internal and external variants seem to be using the external
svn.exe. Each variant relies on a different build. Both builds are using all
4 cores here while the download is running (FG normally uses only 1 and a
bit) I _think_ that's good to see. Do we require Windows users to have
installed svn? I have - and that seems to be what is being used. 

7. The external variant would seem to meet Csaba's design ideal, without any
apparent drawback. Except from the fact that, AFAIKS, apart from the menu
item, both the external and internal variants are the same. Perhaps that's
not the case for Linux builds. Or perhaps I'm wrong in my assessment. If the
2 builds are in fact different perhaps the build variant internal/external
could be made conditional. 

Summary. We seem to have ended up with 3 overlapping systems, all with
advantages and disadvantages. Would it be possible to combine them? It
certainly would not seem sensible to maintain all 3.


Vivian



   


 

  

  



--
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] Heads up: scenery download /built-interrasync

[Vivian Meazza]

ThorstenB wrote:

> 
> You need to provide a target directory for the scenery. This message
> means the target directory is completely empty (or contains white-spaces
> only). See directory configured in the "scenery download" GUI.
> Stuart's suggestion to use a default target may be a good idea.
> 
> > Today, with the new GIT  the Flightgear program crashes. Here is a stack
> > trace:
> 
> Thanks, a string boundary problem - should be fixed right now. The new
> check to avoid svn from crashing on trailing "/" was missing a pair of
> parenthesis.
> 

With the latest Jenkins or Local builds I get this:

Starting automatic scenery download/synchronization. Using external SVN
utility
'C:/Program Files/Subversion/bin/svn'. Directory: 'D:/Git_New/terrasync'.
'C:/Program' is not recognized as an internal or external command,
operable program or batch file.

Looks like a white space issue to me.

When svn.exe is in the path I get:

Starting automatic scenery download/synchronization. Using external SVN
utility
'svn'. Directory: 'D:/Git_New/terrasync'.
The filename, directory name, or volume label syntax is incorrect.

Missing something? I'm probably doing something wrong. Any guidance?

The Built-in download works correctly.

Vivian



--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Heads up: scenery download /built-interrasync

[Vivian Meazza]

Alan wrote

> --
> From: "Vivian Meazza" 
> Sent: Wednesday, June 22, 2011 11:32 PM
> To: "'FlightGear developers discussions'"
> 
> Subject: Re: [Flightgear-devel] Heads up: scenery download
> /built-interrasync
> 
> > ThorstenB wrote:
> >
> >>
> >> You need to provide a target directory for the scenery. This message
> >> means the target directory is completely empty (or contains white-
> spaces
> >> only). See directory configured in the "scenery download" GUI.
> >> Stuart's suggestion to use a default target may be a good idea.
> >>
> >> > Today, with the new GIT  the Flightgear program crashes. Here is a
> >> > stack
> >> > trace:
> >>
> >> Thanks, a string boundary problem - should be fixed right now. The new
> >> check to avoid svn from crashing on trailing "/" was missing a pair of
> >> parenthesis.
> >>
> >
> > With the latest Jenkins or Local builds I get this:
> >
> > Starting automatic scenery download/synchronization. Using external SVN
> > utility
> > 'C:/Program Files/Subversion/bin/svn'. Directory:
> 'D:/Git_New/terrasync'.
> > 'C:/Program' is not recognized as an internal or external command,
> > operable program or batch file.
> >
> > Looks like a white space issue to me.
> >
> > When svn.exe is in the path I get:
> >
> > Starting automatic scenery download/synchronization. Using external SVN
> > utility
> > 'svn'. Directory: 'D:/Git_New/terrasync'.
> > The filename, directory name, or volume label syntax is incorrect.
> >
> > Missing something? I'm probably doing something wrong. Any guidance?
> >
> > The Built-in download works correctly.
> >
> > Vivian
> >
> I have this on my MSVC10 machine and have put it down to cmake not finding
> the SVN libraries. ( Note. I have given cmake the path to the SVN
> includes.)
> 
> If you look into the simgear\CMakeModules\FindSvnClient.cmake the SVN
> search
> paths are all unix style ones such  /usr/local, but I have not looked any
> further into the problem.
> 
> All is OK on MSVC9, which is not encumbered with cmake.
> 

I'm getting this problem on the latest Jenkins build #345, which I
understand uses MSVC9, as well as my local MSVC9 build. Interesting to know
that you aren't getting it with your local MSVC9 build. I'll look into it
some more.

Vivian



--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Heads up: scenery download /built-interrasync

[Vivian Meazza]

ThorstenB wrote

> On 23.06.2011 00:32, Vivian Meazza wrote:
>   Looks like a white space issue to me.
> >
> > When svn.exe is in the path I get:
> >
> > Starting automatic scenery download/synchronization. Using external SVN
> > utility
> > 'svn'. Directory: 'D:/Git_New/terrasync'.
> > The filename, directory name, or volume label syntax is incorrect.
> 
> Enclosing all paths in quotes, i.e. calling
>   "c:\Program Files\foo\svn.exe" checkout "d:\white space"
> instead of
>   c:\Program Files\foo\svn.exe checkout d:\white space
> usually fixes white-space issues when building command-lines. It does so
> for Linux (and pretty sure Mac). But as you report, apparently it
> doesn't help with Windows.
> 
> Such paths never worked for original terrasync(.exe) with external svn
> support. I've disabled the use of white spaces for Windows now, when
> using the external utility. Doesn't fix the issue, but at least people
> get a meaningful error message and are told to use a different directory.
> Anyone running Windows and able to investigate the issue, is welcome to
> look at why calling a Windows command-line utility doesn't accept quoted
> paths (with white-spaces).
> 

This works:

D:\New Git>svn info "C:/Program Files/FlightGear/terrasync/Models"
Path: C:\Program Files\FlightGear\terrasync\Models
URL: http://terrascenery.googlecode.com/svn/trunk/data/Scenery/Models
Repository Root: http://terrascenery.googlecode.com/svn
Repository UUID: 383cc0dc-9303-11dd-9049-4d0e41e9b215
Revision: 16328
Node Kind: directory
Schedule: normal
Last Changed Author: goo...@mgras.net
Last Changed Rev: 16305
Last Changed Date: 2011-06-20 12:47:41 +0100 (Mon, 20 Jun 2011)

Notice that there are white spaces everywhere. C:/"Program
Files"/FlightGear/terrasync/Models also works.

This does not work:

D:\New Git>svn info "C:/Program Files/FlightGear/terrasync"
svn: 'C:\Program Files\FlightGear\terrasync' is not a working copy. 

In fact, none of the other directories under terrasync are recognized by
svn. I don't have a clue how it ever worked, except to say it did actually
work before the last update. Of course, that might have indeed been pure
chance.

Is this any help?

Vivian  







--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Heads up: scenery download /built-interrasync

[Vivian Meazza]

Torsten wrote,

> 
> 
> > I also know that quoting white-space paths works well in "command.com"
> > Windows shells. But apparently it didn't work when terrasync called the
> > "system" function to call "svn". Unfortunately I have no means to test
> > any of this on Windows.
> The following patch seem to do the trick for me, it allow whitespace in
> the command and in the local path name.
> It simply wraps the entire system() command in "" and uses backslash
> instead of forward slash for the path
> separator in the local path.
> 
> Please check, if it works for you.
> 

Nope.

I added a few extra alerts, and got this:

svn: 'D:/terrasync' does not appear to be a URL
Failed to synchronize directory ext'Objects/w130n30/w122n37', error code= 1
sync command ext '"svn checkout -q
http://terrascenery.googlecode.com/svn/trunk/
data/Scenery/Terrain/w130n30/w122n37 D:/terrasync
test\Terrain/w130n30/w122n37"'

Looks to me as if the command has to include no white space, and that's it.
Perhaps we should accept it, make sure the user is aware of it, and leave it
at that. It's a pooh trap because all sorts of directories with spaces are
created automatically by Windows - "Program Files" is only one such.

Vivian



--
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-d2d-c1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository

[Vivian Meazza]

Erik wrote

 
> On Fri, 2011-06-24 at 10:48 +, TDO_Brandano - wrote:
> > Ok, before I get flamed to a crisp, let me explain what is my
> > reasoning behind this. Right now the fgdata repository is about 9 GB.
> > This makes it really, really difficult to obtain an initial checkout
> > of the fgdata folder, expecially for people that do not have a very
> > good connection. at the same time it is not possible, to my knowledge,
> > to only grab part of the repository. And most people don't really need
> > he entire repository anyway. GIT is fantastic to handle code with many
> > contributors, but I think it is really overkill for airplanes, where
> > usually the number of people contributing to a single plane is fairly
> > small and is unlikely that two people should work on the same file at
> > the same time. Also, using SVN for planes the same way that is being
> > used for scenery would allow individual planes to be pulled by a
> > frontend, much like scenery is. Or even to be pulled by FGFS itself,
> > though that's probably science fiction at this moment in time. So, is
> > this something that could be implemented in the future? Am I barking
> > up the wrong tree? I can foresee some issues, like, where should the
> > repository be hosted, any other thing I have overlooked?
> 
> It has been proposed before and I believe it's the way to go. It's just
> a matter of someone stepping up for the task.
> 

Something must be done, this is something, therefore it should be done :-).

Seriously, Git has never been right for the data. We were promised a fix,
which has never materialized. SVN can be no worse, and it might be better.
Terrasync indicates that it might well be better, and might give us the
ability to pull aircraft down for MP on the fly.

I agree with Erik. 

Perhaps Alessandro would take this forward with some more concrete proposals
that we could consider.

Vivian



--
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-d2d-c1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository

[Vivian Meazza]

Csaba wrote

 
> On Fri, Jun 24, 2011 at 1:13 PM, Vivian Meazza
>  wrote:
> >
> > Seriously, Git has never been right for the data. We were promised a
> fix,
> > which has never materialized. SVN can be no worse, and it might be
> better.
> > Terrasync indicates that it might well be better, and might give us the
> > ability to pull aircraft down for MP on the fly.
> 
> Ok, here is my usual negative comment (only by request :P)
> Could we please forget SVN forever? Thank you. Applies to scenery too,
> although I have been told its use was introduced to get free hosting
> from google and not for technical merit.
> 
> Using SVN so you can download stuff on the fly is ridiculous, that's
> not the task of a revision control system (and built scenery probably
> doesn't need a revision control anyway). For all development tasks SVN
> is clearly worse than GIT (branches, local changes, merge requests,
> client side history, backups, etc.), and it isn't particularly good at
> the download part either. Also, an eventual automated aircraft
> download system should allow for 3rd party hangars too (would be the
> most important benefit, if you ask me), and not force SVN upon
> everybody. We should keep it simple, and probably just use regular
> snapshots from the revision control system made available via http.
> 
> To summarize: if we want to split fgdata or allow automatic aircraft
> (model) downloads, that's fine with me, but I don't think SVN is the
> right tool for the task(s).
> 


All good stuff - but when are we likely to see this hypothetical improved
system? 

So what is the right tool? Our Git repo is clearly not fit for purpose as it
stands, and I'm really fed up with doing battle with it with inadequate
weapons.

Vivian

 



--
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-d2d-c1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Heads up: scenery download /built-interrasync

[Vivian Meazza]

Torsten wrote

> 
> Am 24.06.11 11:09, schrieb Vivian Meazza:
> > Looks to me as if the command has to include no white space, and that's
> it.
> No, it may contain white space. It's just that we mix backslash and
> forward slash in the local path.
> 
> This:
> D:/terrasync test\Terrain/w130n30/w122n37
> Is a complete mess (from Windows point of view).
> I'll work on a solution later, probably today.
> 

Is this built-in function:

svn_path_uri_encode()

any help?



--
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-d2d-c1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository

[Vivian Meazza]

Alessandro,

 

Seems like good summary to me.

 

You mean that I've been working on terrasync/svn for nearly 2 weeks, and
it's unnecessary? As I recall it, at least part of the choice of SVN for the
scenery repo was that Windows didn't have a native rsync utility, and SVN
represented a fairly ready-made alternative. The choice of Google might well
have been influenced by the cost. 

 

Why don't you just do it? You don't need full access to Gitorious data repo
to produce a proof-of-principle repo using the proposed structure. If it
works, and the bugs have been ironed, then all the data could be migrated to
it. And in any case we shouldn't abandon the old until the new is up and
running.

 

Vivian

 

-Original Message-
From: TDO_Brandano - [mailto:tdo_brand...@hotmail.com] 
Sent: 24 June 2011 18:46
To: Flightgear Devel List
Subject: Re: [Flightgear-devel] Proposal: Move airplanes to an SVN
repository

 

Ok, let me sum up a few of the day's IRC discussions.
The size of the GIT repository is a real issue, and I am not the only one
that perceives it as such. At the same time, SVN suffers from several
disadvantages compared to GIT, even from the point of view of reliability.
Even the map data should not really be hosted on SVN, but it's mainly hosted
there because we get that hosting for free from Google. Everyone agrees that
the Aircraft data would be better off split aside from the rest of fgdata
now that FGFS can load them from a separate folder. Several people find the
idea of loading single planes at launch time or at runtime interesting. SVN
is not really required to do this, the planes could be hosted on a separate
server as archives and either installed, or, in the far future, loaded as
compressed archives. To do this there must be some sort of structure keeping
track of dependencies for single planes, version compatibility and available
planes so that download packages can be generated automatically and
developers can download the entire thing via a script or something similar
if they want to. The ideal situation would have a repository for each
aircraft or for each author, to allow individual authors GIT access for
their own planes. There's planes where the author is unknown or is long
missing, and those will need anyway to be kept under version control since
changes to FGFS might break compatibility in the future. Also, fragmenting
the repository might mean that some author could choose to use a different
or more recent license for her plane, so we need to keep track of this info
as well. At the very least an automatic downloader should either filter the
downloads based on license or prompt the user for approval. Someone on IRC
has volunteered to do this work, but I won't name names until I am sure he
is being serious and that he is reliable, since I think he would need some
pretty powerful rights on the repository to do this. Am I missing anything
else?

Alessandro (Brandano)

> Date: Fri, 24 Jun 2011 17:41:36 +0200
> From: flightg...@sablonier.ch
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] Proposal: Move airplanes to an SVN
repository
> 
> Am 24.06.11 12:55, schrieb Erik Hofman:
> > On Fri, 2011-06-24 at 10:48 +, TDO_Brandano - wrote:
> >> Ok, before I get flamed to a crisp, let me explain what is my
> >> reasoning behind this. Right now the fgdata repository is about 9 GB.
> >
> > It has been proposed before and I believe it's the way to go. It's just
> > a matter of someone stepping up for the task.
> >
> > Erik
> >
> 
> Everyone is free to build a own "hangar" on gitorious, everyone is free 
> to develop, exchange, merge in, push, to discuss and bring different 
> aircrafts together in his own hangar. No hierarchical centralized system 
> is needed with git and gitorious/github, you merge in or push whatever 
> you want. People can clone, pull, merge, push, watch, organize, whatever 
> they want. No one will ask. You collaborate or not, you build your own 
> hangar, it is your choice, YOU set permissions, YOU give access, YOU 
> share permissions or not. You give people links here and there to 
> provide "your" aircrafts or aircrafts of "canadian group of most serious 
> aircrafts" or whatelse. An educational hangar, a polar ice hangar, a 
> chopper hangar, a historical hangar ...
> 
> I really don't know why most people here use gitorious and git like a 
> hierarchical system of the romans with asking for permissions, sending 
> merge requests to some development sub-kings, waiting for this and that. 
> It is not necessary, just see the freedom, use git as it is probably 
> thought, and open your own personal-number-one-hangar, show your work, 
> and "git reset --hard" yourself when necessary ;-)
> 
> And meantime fgdata core developers try to find consensus about 10 or 15 
> aircrafts remaining in basic fgdata (Arghh! Consensus!). That is what 
> was requested here some months ago (hey, fgdata core developers, with 
> all my respect, don't f