Re: [Flightgear-devel] ATISs upgrade
John Denker wrote: > http://www.av8n.com/fly/fgfs/vce-wav.tgz > > *) Louder. This comes at the cost of some distortion, but overall >much more readable (in the presence of other noise). > > *) Many "fake" words added ... words necessary for ATIS. >Strange words are better than silence, in the short run. >(In the long run, this whole voice system needs to be re-engineered.) > > > > http://www.av8n.com/fly/fgfs/atis.diff > > *) Get rid of some memory leaks. > > *) Keep track of which ATC services are active on which radios. > > ... < SNIP LOTS! > ... > > *) et cetera. > > Hi John, That all sounds like good stuff. Unfortunately I don't have the time to test it at the moment, or a working OSG FG. Have you recorded a new sound file, or just edited bits of the existing words to create the new ones? It's become increasingly clear to me that I simply don't have the time to keep up with all the areas of code that I was working on, since changing my job and taking up real-life aviation in my spare time (I passed my paragliding 'CP' rating last summer and can now go flying on my own, weather permitting). The ATC stuff seems like a good chunk to give up looking after, since it's so open ended that it simply can't ever be finished, and it's too big to easily dip in and out of without a good chunk of time. The upshot is, that if anyone with CVS access wants to review and commit this, please do so if you think it's OK. I'll eventually look at it if not, but won't commit it untested. And if anyone wants to take over 'ownership' of the ATC code that I wrote, for whatever that concept is worth in an OS program ;-), then please do so. Or start again and write a better one - I wouldn't be upset if it was ripped out, as long as it was for something better. I know that there's at least one person out there who's very frustrated with the crashes in the tower code that I still haven't got round to fixing. Cheers - Dave - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] MP server status page.
Hi all, A little thing I done to check status of online servers: http://mpserver05.flightgear.org/fgmp/status/ Nick - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] no texture mipmaps ?
Hi, I've just built FG with with a fresh checkout and I have the impression that there is no mipmaping done for scenary objects. That was a quick fly with the ufo around ksfo so I could see that problem on buildings, bridges, etc. Or is there some osg env var to set ? Harald. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ATISs upgrade
On Fri, 2 Mar 2007, John Denker wrote: > On 03/01/2007 02:19 PM, AJ MacLeod wrote: >> Was the stuff at line 300 intended to be in there? > > Actually yes, I put the call-trace in there for a reason, and I left > it in there for a reason. I thought that in the future, some folks > might find it helpful to see how/where this code was being called. Anyone who needs that backtrace can do it himself. Those who don't even know how to do set breakpoints and do a simple backtrace with a debugger, won't understand sourcecode anyway. Just like soucecode, saved backtraces would be documentation of implementation, not design. The latter is something that could be improved a lot for FG. :P I'm not sure the sourcecode files is the right place for that though, being limited to ascii plaintext; and by the risk of having the documentation deleted by accident or misunderstandings; and in that it isn't allways obvious that a design idea is connected to one particular position in the code. Someone editing another source file may miss it together. Maybe we should have a design documentation wiki? (Then just refer to sections there from the source when necessary.) And Melchior is our source tree janitor whose job is act "troll on the bridge" and keep the code nice and tidy. So just do as he says regarding the cosmetics so we can get the stuff in already, OK. =) Good work with cleaning up the ATIS mess. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ATISs upgrade
* John Denker -- Sunday 04 March 2007: > It would be necessary to deal with the fact that there can be N different > "ATC" messages tuned up at the same time, Whereby all are spoken with the same voice, and all are printed to the single one terminal. Using a single message property wouldn't make the situation any worse. But, OK, let's keep it in the /instrumentation/*/atis property, with a reduced chance of it appearing somewhere. Because, again, it won't be printed to the terminal by default. Unless Curt rules that it be there, basically abandoning the logging system. > 2) Even if it worked, such code would be undesirable ... because the > idea of receiving a textual ATIS during flight is unrealistic, I'm not sure if you just didn't get what I wrote, or if you are intentionally misrepresenting it to make your point stronger. I wrote: * Melchior FRANZ -- Sunday 04 March 2007: > Everyone interested in having the ATIS messages > in the terminal can then [...] > Or add this to have the ATIS messages printed on top of the screen: Can you understand that? "everyone interested *can*"? As opposed to your "cout" that forces this on everyone without possibility to avoid it. The rest of your counter argument is based on your wrong assumption and thus void. Sigh, I give up. m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ATISs upgrade
On 03/04/2007 05:37 AM, Melchior FRANZ wrote:
> _setlistener("/sim/messages/atis", func { print(cmdarg().getValue()) });
...
> _setlistener("/sim/messages/atis", func {
> setprop("/sim/screen/blue", cmdarg().getValue());
> });
1) I'm afraid the code would have to be more complicated than that.
It would be necessary to deal with the fact that there can be N different
"ATC" messages tuned up at the same time, where N >= 4 is common even in
simple GA aircraft.
2) Even if it worked, such code would be undesirable ... because the
idea of receiving a textual ATIS during flight is unrealistic, in
today's general-aviation fleet at least.
Printing ATIS text to the console is
a) not a debug message, and
b) not a feature.
It is a temporary workaround to deal with multiple bugs in other subsystems,
including:
-- There are problems with the audio levels in the "simple" TTS system.
-- The FG interface to the "festival" TTS is broken, as previously reported.
-- A goodly number of aircraft are using comm radios that don't even have
volume-setting knobs.
-- et cetera.
3a) Writing the ATIS text to the logfile would not be an improvement, and
would not solve the aforementioned problems.
3b) Writing the ATIS text to a bluescreen would not be an improvement, and
would not solve the aforementioned problems.
3c) Making ATIS text available via a popup via the "debug" menu would be
complicated and IMHO not worth the trouble. It would be a misuse of
resources. The development resources would be better spent fixing some
of the aforementioned bugs in the audio system.
Sometimes it is not possible to fix all the world's bugs at once.
The concept of /temporary workaround/ is a well-established concept.
More generally, there is a saying:
"Do not let the perfect be the enemy of the good."
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ATISs upgrade
* John Denker -- Sunday 04 March 2007:
> On 03/03/2007 05:18 PM, Durk Talsma wrote:
> > Personally, I don't object against commented-out cout / cerr statements
> > in the code if the author wants to retain them for ongoing development.
>
> Agreed!
>
> There are thousands of such couts in the code already, and they serve
> a useful purpose.
Again, I didn't say/mean that commented out "cout" must be removed, but
only active ones, of which there were a lot, and there are still some left:
+ cout << " ATIS active on:";
[...]
+ cout << " " << endl;
+ cout << transmission << endl;
This *needs* to be SG_LOG with log-level "info". It is neither "alert"
nor "warn". If you don't remove them now, then I'll just remove them
once it's committed. With the difference that I won't put SG_LOG
replacements there. Your call. :-P
And this is not *my* idea. This is how the system was designed. And
there were times where other developers took care of that. Nowadays
I seem to be the only one left who still tries to keep things clean
and consistent, even if that means occasional hate mails. It should
be the project leader's job to receive hate mails, not mine. ;-)
[from the original post]
> *) ATIS messages now in property tree, so it can be read e.g. by the
> http interface.
This is a good thing, but for consistency reasons it should not be
written to "/instrumentation/" + act->first + "/atis", but to
/sim/messages/atis. The /sim/messages/* properties are exactly for such
purposes. Other subsystems are already posting messages there.
See $FG_ROOT/Nasal/screen.nas, where listeners are attached to display
messages on screen. Everyone interested in having the ATIS messages
in the terminal can then easily add this to a local Nasal file:
_setlistener("/sim/messages/atis", func { print(cmdarg().getValue()) });
... and those not interested in the messages don't have their terminal
cluttered with stuff, when they are actually only interested in their
own debug messages (such as from temporarily uncommented cout ;-).
Or add this to have the ATIS messages printed on top of the screen:
_setlistener("/sim/messages/atis", func {
setprop("/sim/screen/blue", cmdarg().getValue());
});
Whereby one would probably have to split the message into single
lines, which is left as an exercise to the student. :-}
m.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
