* Josh Babcock -- Tuesday 20 December 2005 02:54:
I wonder what the performance hist will be. I assume that it will
go linearly with the number of vertecies.
I only had two spheres side by side in the scenery (next to the bo105
in KMRY), with 92 vertices each. They were constantly morphing into
Tween method (for the curious ones):
That's how you would current set up such an animation. First you
organize your objects in the 3D modeler like so:
|___wing
|normal
| |main
| |aileron
| |...
|
|bent
* Ralf Gerlich -- Tuesday 20 December 2005 10:16:
Melchior FRANZ schrieb:
Unfortunately, so far it only works with solid (unsmoothed) objects.
Looks like a plib bug to me, but I have yet to find the exact reason.
Maybe the normals of the faces don't get interpolated as well? (Just a
stab
* Erik Hofman -- Tuesday 20 December 2005 10:26:
Melchior FRANZ wrote:
In theory, aileron/flap/... movements should still work.
I'm afraid they don't work properly anymore since the center
point and the normal axis' probably have changed after the animation...
Yes, possibly. I just hoped
* Melchior FRANZ -- Tuesday 20 December 2005 10:46:
I just hoped that the transformation would somehow
be morphed, too. Steve is using tweening for his exposer, and I
would be a bit surprised if he hadn't thought of that.
Hmm ... no. I take that back. Will hardly be considered by
plib
* Ralf Gerlich -- Tuesday 20 December 2005 15:16:
Just an idea, but would it help to define a specialised bending
animation instead of the general purpose morph?
Why instead?
Adding a bend animation would probably not be that hard for someone
proficient with vector calculation. Which I am
* Melchior FRANZ -- Tuesday 20 December 2005 02:22:
* Ampere K. Hardraade -- Tuesday 20 December 2005 02:00:
I'm not too excited about having to create another instance of the wings.
Good news for you: you don't have to do *anything*! (Was the bitching
on IRC not enough?)
Umm ... sorry
* Vivian Meazza -- Monday 19 December 2005 09:55:
(C) tween method: this isn't implemented in fgfs yet, but plib offers
an ssgTweenController (A morph controller) class.
There might well be other applications for this animation: I'm thinking
of pilot animation in particular.
I had
* Ampere K. Hardraade -- Tuesday 20 December 2005 02:00:
I am looking forward to it, although I'm not too excited about having to
create another instance of the wings.
Good news for you: you don't have to do *anything*! (Was the bitching
on IRC not enough?)
m.
* Buchanan, Stuart -- Sunday 18 December 2005 21:50:
In particular a number of the surfaces are one-sided which causes
problems when combined with transparent surfaces like the windows.
No. That's normally caused by wrong object order in the *.ac file.
You can either re-order the objects there,
* Jon S. Berndt -- Monday 19 December 2005 05:04:
Would it be possible to change the visual appearance of wing flex during
flight?
As Curt and Joacim have mentioned already, there are ways to do it:
(A) ornithopter method: several instances of the wing. This has the
disadvantage that you'd
Sorry to be annoying yet again, but that's what I'm best at:
* Erik Hofman -- Saturday 17 December 2005 10:48:
I must say I like the idea, but given it's current state (no windows
support) I would like to postpone it until after FlightGear 1.0 is released.
And I would like to postpone the
* Curtis L. Olson -- Thursday 15 December 2005 19:21:
In the past with Debin and Glut, specifying --enable-game-mode has
always worked for me as expected. But now I'm trying to do the same
thing with freeglut-2.2.0 and Fedora Core 4.
Don't know if it has anything to do with it:
* Curtis L. Olson -- Thursday 15 December 2005 21:06:
I have verified that glut game mode works great with the original
glut-3.7, but it's horribly broken in freeglut.
Keyboard handling is also broken in freeglut. That's why I'm using
SDL. (I don't like unfreeglut :-).
m.
* Vassilii Khachaturov -- Wednesday 14 December 2005 21:41:
And now comes the attachment... Sorry.
1) You didn't even try the patch. I didn't either, but I see that
it can't work. Hint: xmllint :-}
2) Polluting joysticks.xml with driver specific stuff is a no-go.
Drivers need to be
* Vassilii Khachaturov -- Wednesday 14 December 2005 23:13:
1) You didn't even try the patch. I didn't either, but I see that
it can't work. Hint: xmllint :-}
I don't know how you see that,
+ disable-cyclic-yoke type=boolfalsedisable-cyclic-yoke
* Martin Spott -- Sunday 11 December 2005 20:09:
Jon S Berndt wrote:
On Sun, 11 Dec 2005 15:02:13 +0100 Melchior FRANZ wrote:
It's the job of the glue code (JSBSim.cxx) to map internal values
to standard fgfs properties. This internal /fdm/jsbsim/foo thingy
will hardly ever
* Georg Vollnhals ([EMAIL PROTECTED]) [051210 17:36]:
I placed 2 objects into the sea near Bremerhaven (EDWB) which can bex
seen from distance but when you come nearer they disappear.
2. Created a file 3089361.stg
OBJECT_STATIC lighthouse.xml 8.48 53.57 0.0 10
OBJECT_STATIC oilrig.ac 8.485
* Buchanan, Stuart -- Wednesday 30 November 2005 18:27:
I would think the .nas file for the KAP140 should be able to
disable the appropriate parts of the menu tree dynamically when initialized.
What should be disabled? Only the Autopilot settings entry, or the
whole Autopilot menu? I wouldn't
* Steve Knoblock -- Wednesday 07 December 2005 20:35:
What should be disabled? Only the Autopilot settings entry, or the
whole Autopilot menu?
What if the Autopilot menu entry was bound to a function [...]
Thanks, but I didn't ask *how* to do it (which I know pretty well),
but *which*
* Melchior FRANZ -- Wednesday 07 December 2005 21:00:
* Steve Knoblock -- Wednesday 07 December 2005 20:35:
What if the Autopilot menu entry was bound to a function [...]
Thanks, but I didn't ask *how* to do it [...]
But, yes, I had planned to let menubar.xml just call gui.autopilot
Don't know if this feature is desirable for 1.0.0: the attached
patch adds an fgCommand that allows to disable/enable menu entries
(menu and item). It could be used for disabling the
Fuel Payload dialog for non-YASim aircraft and to disable the
autopilot dialog when it has no effect on the used
* Melchior FRANZ -- Tuesday 06 December 2005 15:20:
the attached patch adds an fgCommand that allows to disable/enable
menu entries
This should better be hooked into the property tree, so that one can
directly set /sim/menubar/default/menu[2]/item[3]/enabled to false and
get the menu disabled
* Melchior FRANZ -- Tuesday 06 December 2005 15:57:
This should better be hooked into the property tree, so that one can
directly set /sim/menubar/default/menu[2]/item[3]/enabled to false and
get the menu disabled.
Done. Attached is a better patch. No more fgCommand, and no Nasal-wrapper
* Melchior FRANZ -- Tuesday 06 December 2005 16:54:
Attached is a better patch.
... and in case someone *really* wants to review that, or maybe even
test it. I fixed one bug and cleaned the code up, and I will probably
make some more minor changes:
http://members.aon.at/mfranz
* Melchior FRANZ -- Tuesday 06 December 2005 17:50:
http://members.aon.at/mfranz/menu_disable.diff [5 kB]
Committed. And I forgot to mention in the cvs log message:
OK'ed by Erik. :-)
m.
___
Flightgear-devel mailing list
Flightgear-devel
* Steve Knoblock -- Tuesday 06 December 2005 21:16:
My only caution would be possible malicious disabling of essential
menus. I think the author would be exposed pretty quickly,
Exactly. And this isn't the first opportunity for aircraft designers
to annoy others. What about a Nasal script that
We discussed it a bit on irc://irc.flightgear.org/flightgear
already ...
* Vassilii Khachaturov -- Saturday 03 December 2005 02:52:
1) it's really difficult to fly a helicopter with the yoke,
but one can make good use of the throttle as the collective.
If one wants to fly and use the mouse as
* Melchior FRANZ -- Friday 02 December 2005 18:44:
I will present a patch after that which restores the
original, pre-ObjectsTerrain behavior.
Committed.
If FG_SCENERY=A:B and both dirs contain a Terrain/ and Objects/
subdir, then FGGlobals::set_fg_scenery() will expanded this to a
list
* Christian Mayer -- Saturday 03 December 2005 12:35:
Melchior FRANZ schrieb:
If FG_SCENERY=A:B and both dirs contain a Terrain/ and Objects/
does the seperator have to be a double colon :?
Or, more precisely, is it a ; under Windos? A double colon would cause
real trouble under Windos
* Harald JOHNSEN -- Saturday 03 December 2005 13:12:
Now the question are :
I guess this is mostly answered in my reply to Christian. People
seem to be unaware of the FG_SCENERY path list. This is not a new
feature. It exists since at least two years (or something). Only
the behavior changed a
* Melchior FRANZ -- Saturday 03 December 2005 16:45:
+union {
+float f;
+int i;
+} v;
Umm ... but is sizeof(float)==sizeof(int) on all supported
platforms? It's not on Atari ST, for example (IIRC). :-/
m.
___
Flightgear
* Alex Romosan -- Friday 02 December 2005 08:16:
Mathias Fröhlich writes:
Please use this one. And I believe, without looking into the code,
that there are likely more of them ...
I'll try all solutions later today. But I don't understand why
any of them should be necessary. The code may
* Alex Romosan -- Friday 02 December 2005 08:16:
please apply the attached patch which uses static_cast:
Haven't yet tested, but it looks good. At least it calls
_Z16XDR_decode_int32RKj. :-)
(gdb) disass XDR_decode_float
Dump of assembler code for function _Z16XDR_decode_floatRKj:
0x0831086e
* Melchior FRANZ -- Friday 02 December 2005 09:57:
* Alex Romosan -- Friday 02 December 2005 08:16:
please apply the attached patch which uses static_cast:
No, this patch doesn't work.
m.
___
Flightgear-devel mailing list
Flightgear-devel
* Harald JOHNSEN -- Friday 02 December 2005 11:36:
Melchior FRANZ wrote:
(why does it not call _Z16XDR_decode_int32RKj? Optimized away?):
decode_int32 is a nop on a x86 anyway
Huh? Looks like a nop for big-endian:
int32_t
XDR_decode_int32 ( const xdr_data_t n_Val )
{
return
* Mathias Fröhlich -- Friday 02 December 2005 07:35:
float
XDR_decode_float ( const xdr_data_t f_Val )
{
union {
float f;
xdr_data_t x;
} tmp;
tmp.x = XDR_decode_int32 (f_Val);
return tmp.f;
}
This works.
Dump of assembler code for function
* Harald JOHNSEN -- Friday 02 December 2005 11:36:
Perhaps adding a volatile modifier on the tmp pointer
could do the trick (of course doing that disables optimisations).
It doesn't.
Dump of assembler code for function _Z16XDR_decode_floatRKj:
0x08310816 _Z16XDR_decode_floatRKj+0: push %ebp
* Andy Ross -- Friday 02 December 2005 16:36:
This violates the strict aliasing rules that are the default for
gcc 4.x -- I believe it issues a warning to that effect.
There's is no warning (using -Wall), and info man page claim
that strict aliasing is turned off by default, even if the
* Curtis L. Olson -- Friday 02 December 2005 16:57:
One of the original intentions of the scenery path was to search until
you found something and then stop.
This is still the case for terrain.btg.gz files and airports, just as it
was before. But objects are always set from all stg files, with
* Curtis L. Olson -- Friday 02 December 2005 18:09:
Again, it's a shame that original functionality is lost when people come
later and make changes to complex code without fully understanding the
intent.
Isn't that one of the reasons why we have flightgear-cvslogs? For
code review? Like in
* Melchior Franz -- Friday 02 December 2005 01:10:
Modified Files:
tiny_xdr.cxx
Log Message:
returning addresses of auto vars is *dangerous* [...]
But ... we weren't really returning the address of an auto var.
Making dummy static fixes the problem, but the reason must be
another one
* Melchior FRANZ -- Friday 02 December 2005 01:43:
But ... we weren't really returning the address of an auto var.
Is it a gcc 4.0.2 (SuSE 10.0) compiler bug? tiny_xdr.cxx contains
this function;
float
XDR_decode_float ( const xdr_data_t f_Val )
{
float* tmp;
xdr_data_t dummy
* Erik Hofman -- Wednesday 30 November 2005 09:56:
How could I tell others to postpone their contribution until after the
release of FlightGear 1.0 [...]
Good question, indeed! How could you? There was no discussion about
this topic on flightgear-devel before this order was announced, and
every
* Curtis L. Olson -- Wednesday 30 November 2005 14:01:
Melchior FRANZ wrote:
There was no discussion about this topic on flightgear-devel before
this order was announced, and every discussion after that was passively
suppressed by ignoring valid arguments. [...]
I don't want to passively
* Curtis L. Olson -- Wednesday 30 November 2005 15:19:
You may want to attack this in small steps ... for instance start out
with just getting save/load of aircraft position working.
As demonstrated before [1], this is quite easy to do even
with Nasal[2]. The only thing that needs to be
* Roy Vegard Ovesen -- Wednesday 30 November 2005 18:16:
Is this possible, Melchior, to disable the autopilot menu entry just for the
C172?
Not currently, AFAIK. Wouldn't be hard to add. One would probably
do that as an fgcommand() that enables/disables menu entries.
Generally, making such
* Jon Berndt -- Sunday 27 November 2005 19:26:
Is there some kind of problem going on with downloading PLIB from CVS?
Notoriously, but not necessary in this case. :-)
Seems there's been a partial outage in progress on SF.net for
weeks. I can't get plib from CVS, though ...
I have just
* Vassilii Khachaturov -- Friday 25 November 2005 22:57:
The following are still in
* the exception classes were lacking the copy ctors and assignment
operators, but the default ones for them were unusable as the string
instance members are not suitable for byte-by-byte copying!
But ...
* Vassilii Khachaturov -- Saturday 26 November 2005 11:02:
But ... classes without copy/assignment operator aren't copied
byte-by-byte, but member-by-member[1].
It's a pity I am at home sick, and without the book. I don't know
what is written in the section you refer to.
There's written
* AJ MacLeod -- Saturday 26 November 2005 15:50:
This hypothetical application sounds very much to me like an extension to the
existing fgrun...
... and we could call it ... *pause* ... fgadmin!
m.
___
Flightgear-devel mailing list
* Mathias Fröhlich -- Saturday 26 November 2005 20:59:
On Samstag 26 November 2005 19:47, Joacim Persson wrote:
fgfs --airport=EGLL --aircraft=ufo
So, since I do not see that problem:
Do you have any modifications in your local tree?
Doesn't work for me either. This works ...
$ fgfs
* Vassilii Khachaturov -- Friday 25 November 2005 15:11:
* whenever an exception object was created on a stack and then thrown
(thus causing the dtor for that object to fire!), it was replaced
with a STATIC exception
The whole thing looks like a solution desperately searching for a
problem.
* Enrique Vaamonde -- Thursday 24 November 2005 09:20:
I have tried to compile FlightGear using the TestRenderTexture.cpp in
the cvs but am unable to compile it, [...]:
I had to make this change first:
diff -u -p -U0 -r1.2 TestRenderTexture.cpp
--- TestRenderTexture.cpp 29 Jan 2005
* Danie Heath -- Tuesday 22 November 2005 10:09:
I am the owner of Aircraft.co.za, and I'm willing to do a
complete review of FlightGear on my site ...
If you have any specific features/aircraft/sceneries I should
focus on, please tell me so I can include it in the review
I don't speak
* Syd Adams:
[...]
Having some trouble with material animation ...
it appears global material changes only affect objects that share the same
texture file
global doesn't only look at what ac3d files define in a MATERIAL entry,
but at all material parameters, including the texture. It affects
* Joacim Persson -- Tuesday 22 November 2005 16:19:
This must be one of the lesser flewn models in FG. Two years has passed
since the last patch, and noone has noticed that Erik forgot (tsk tsk) that
there are /two/ rotors on the Chinook.
Could well have been my patch, not Erik's. All
* syd -- Wednesday 23 November 2005 02:31:
If I understand you correctly , I need to list all objects that
the animation applies to ? I was doing this before , (without
global ) and everything worked fine ... but in the documentation
it says using an object and global affects all objects that
* Vassilii Khachaturov -- Monday 21 November 2005 11:39:
Perhaps the non-local models should have a luminous fake light
like the other lights in fg for this reason.
Yes. Lights could also be assigned after priorities. You own machine's
taxi lights have highest priority, then come landing
* Buchanan, Stuart -- Monday 21 November 2005 10:49:
do I just need to add some light objects to my aircraft model and some
nasal code to switch them on?
With this patch, yes. You don't even need Nasal code. Just a light
definition block in your model xml file. It gets its on/off state
from
* Vassilii Khachaturov -- Monday 21 November 2005 12:27:
Do you have a set of nice sliders to adjust the glLight parameters
on the light object in real time, like the ones you've built for
the bo105 exteriour adjustment?
Not yet, but I'll write one. And for the record: I didn't do the
* Buchanan, Stuart -- Monday 21 November 2005 13:39:
Ah, I didn't realize I needed a patch for it. You mentioned that the patch
was from IRC. Do you have a record of it I could plunder to patch my code
tree?
http://people.freebsd.org/~jylefort/flightgear-aircraft-lights.diff [8 kB]
But it
* Buchanan, Stuart -- Monday 21 November 2005 13:39:
--- Melchior FRANZ ... @aon.at wrote:
Oh, and thanks for posting my email address. I had already
feared that I wouldn't get enough spam in the next time. But
thanks to people like you this is completely unjustified.
m
* Buchanan, Stuart -- Monday 21 November 2005 15:29:
I thought I was doing quite well - avoiding top-posting, snipping etc. My
sincere apologies that you had to be part of my learning process.
Hey, if I search long enough, I always find something. :-}
[...] offence by missing out on some
* Melchior FRANZ -- Saturday 19 November 2005 14:11:
One new feature *must* go in. Otherwise the 1.0.0 release number is
IMHO not justified:
* landing lights
... to make fgfs actually usable at night
* aircraft switchable at runtime
And here's another one:
* save gui configuration
* Erik Hofman -- Friday 18 November 2005 18:36:
After this release we'll only accept bug-fixes to the code, except for
the new JSBSim version. Any major code changes that are not intended to
fix one or more bugs will have to wait.
One new feature *must* go in. Otherwise the 1.0.0 release
I also hoped that a few Nasal improvements could be committed,
such as file I/O. That's hardly dangerous for overall fgfs
stability, and would allow to implement some nice features
in Nasal scripts. (Not that this had to be in 1.0.0, but I
wouldn't like to wait some months for it. :-)
m.
* Rodrigo Flores -- Saturday 19 November 2005 16:18:
Finally, the old fonts in the FG 0.9.8 format are still there, couldn´t
see the fonts showed in the Concorde screenshot.
You have to switch the GUI style with Shift-F10, or put this into your
~/.fgfsrc or use it on the command line or in
* Dave Culp -- Thursday 17 November 2005 17:36:
On Thursday 17 November 2005 09:45 am, Melchior FRANZ wrote:
Here are four screenshot offerings for the FlightGear page.
...
http://members.aon.at/mfranz/seafire-nimitz.jpg [70 kB]
Well, *that's* a fine time for the engine
* Dave Culp -- Thursday 17 November 2005 18:37:
OK, but it still looks odd. BTW, very nice screenshots.
The problem is that the prop disk would also look odd. This would exactly
look like a screenshot from a simulator, while I wanted to make it look
as much as possible like a photo. Just to
* Josh Babcock -- Wednesday 16 November 2005 23:25:
I considered using a Nasal script, but I don't know how the
script would know when the winter textures are being used.
if (getprop(/sim/startup/season) == winter) { ?? }
m.
___
Flightgear-devel
* Ampere K. Hardraade -- Thursday 17 November 2005 01:50:
On November 16, 2005 05:37 pm, Melchior FRANZ wrote:
* Josh Babcock -- Wednesday 16 November 2005 23:25:
I considered using a Nasal script, but I don't know how the
script would know when the winter textures are being used
* Ivo -- Thursday 17 November 2005 04:31:
On Thursday 17 November 2005 01:50, Ampere K. Hardraade wrote:
Speaking of snow: is there anything about snow accumlation in METAR data?
I'm just curious.
Well, there's this:
Format: SNINCR [i/g]
But that's not standard METAR, but
* Melchior FRANZ -- Monday 14 November 2005 22:29:
The strange thing is, that the return value that triggers assert()
is 35, or EAGAIN (Linux). This makes no sense. It's neither described
on the pthread_join manpage, nor is it used in any implementation that
I found on the net.
BS! I've
* Wendell Turner -- Wednesday 16 November 2005 04:16:
However, with this evening's CVS, with that argument, I
get this:
WARNING: Network: 17: unhandled write
Bus error
and fgfs halts.
[...]
plib, simgear, fgfs, data: cvs updated as of 15.nov.05 10pm ET
plib CVS/HEAD has broken
* Vassilii Khachaturov -- Monday 14 November 2005 12:50:
http://members.aon.at/mfranz/flightgear/flightgear-howto.html
I'd only suggest to have the world scenery under smth like
/var/share/FlightGear/WorldScenery
(maybe share/games) rather than in the FG_ROOT, to make it
more up-to-date
* Curtis L. Olson -- Monday 14 November 2005 15:12:
Let's stick with .../.../Scenery/[Terrain|Objects] on all platforms
please. Individuals are welcome to call it whatever they want on their
system and use the --fg-scenery= option to point to their favoritely
named directory.
Maybe I
* Buchanan, Stuart -- Monday 14 November 2005 16:06:
Am I correct in thinking that someone using terrasync should have their
terrasync data in a different directory from their directly-downloaded
10x10 scenery?
No. On the contrary.
If so, is the convention to name the directories as
* Curtis L. Olson -- Monday 14 November 2005 16:34:
Melchior FRANZ wrote:
This dir doesn't exist. There's no such thing as $FG_ROOT/data/.
Of course there is. :-)
Sheesh. I resign. :-}
$FG_ROOT/source/
$FG_ROOT/data/
$FG_ROOT/data/Aircraft/
$FG_ROOT/data/Scenery
* Curtis L. Olson -- Monday 14 November 2005 16:54:
This is a hopeless conversation because everyone wants to do it
different and there are so many possibilities.
We are talking about different things. You talk about the organization
of source and data in your home directory. I talk about
* Harald JOHNSEN -- Saturday 12 November 2005 17:09:
Melchior FRANZ wrote:
I've just implemented the check for stale METAR reports (to stop
fetching after 10 stale reports). This triggers an assert in
SGThread:
It's perhaps because of the PTHREAD_CREATE_DETACHED attribute of the thread
* Oliver C. -- Monday 14 November 2005 18:46:
[/usr/local/games/FlightGear or /opt/flightgear]
Seriously, i can live with both directories. /opt/flightgear is fine too.
Both are wrong, according to the FHS, and to common sense. The right path
is /usr/local/share/ ... and guess what? It's
* Erik Hofman -- Monday 14 November 2005 18:47:
If it's causing any troubles I would remove the first three lined of
SGThread::start() since we've done without it for many years.
It is causing troubles: the pthread_join manpage says:
The joined thread th must be in the joinable state: it
Unfortunately, reverting the recent changes (that caused the thread
to be created with detached state) wasn't enough to fix the problem.
The strange thing is, that the return value that triggers assert()
is 35, or EAGAIN (Linux). This makes no sense. It's neither described
on the pthread_join
* Melchior FRANZ -- Monday 14 November 2005 22:29:
$ fgfs --aircraft=ufo --prop:/environment/params/metar-max-age-min=1
--log-level=warn
I forgot --enable-real-weather-fetch.
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
I've just implemented the check for stale METAR reports (to stop
fetching after 10 stale reports). This triggers an assert in
SGThread:
fgfs: /usr/local/include/simgear/threads/SGThread.hxx:155:
void SGThread::join(): Assertion `status == 0' failed.
I don't know much about threads. Could
* Stewart Andreason -- Saturday 12 November 2005 18:00:
1. when running flightgear, press [ESC] , then [TAB] (intending to move
the cursor to the cancel button)
Cycling widget focus with TAB is not implemented, and never was.
instead the instrument settings dialog comes up. ok. But: I can
* Ampere K. Hardraade -- Saturday 12 November 2005 19:31:
You can get SDL and use the --enable-sdl flag when running configure for
FlightGear.
Which also fixes repeatable keys. freeglut is neither compatible with
SDL nor with legacy glut.
m.
___
* Martin Spott -- Saturday 12 November 2005 20:43:
Z2h0Z2Vhci1kZXZlbAo+IDJmNTg1ZWVlYTAyZTJjNzlkN2IxZDhjNDk2M2JhZTJkCj4KCgoKLS0K
PEFydGh1ci8+Ci0gaHR0cDovL3NvdXJjZWZvcmdlLm5ldC91c2Vycy9hcnRvb3JvLwotIGh0dHA6
Ly9hcnRvb3JvLmJsb2dzcG90LmNvbQo=
So, why are you posting this crap ? Please stop it,
* Curtis L. Olson -- Saturday 12 November 2005 21:03:
Hey, what's wrong with ed /var/mail/curt ...
Hey, and what's wrong with mimencode -u and recode utf8:latin1?
As I said: it would be nicer in ASCII, but base64 isn't an offense,
unlike HTML, fullquoting, topposting, which are the real
* Martin Spott -- Saturday 12 November 2005 21:33:
You know as good as I do that by common practice encoded emails don't
belong into mailing lists -
Sure, just like HTML, top-posting, full-quoting, Yet it happens. I tell
people once to follow the rules, but if they don't and don't have
Those using the alternative dark GUI theme may want to update plib/cvs.
All packagers should IMHO do that in any case. This fixes two problems:
- The maximum length of entries in the property viewer was changed
from 80 to 256. The old value affected a few longer entries, like
the METAR
* Erik Hofman -- Friday 11 November 2005 14:07:
How should we proceed at this point; add it prior to 0.9.9, or add it
for 1.0 and provide a patch for 0.9.9?
I'm strongly in favor of 0.9.9. If it takes us as long to get 1.0.0
out as it took us for 0.9.9, then there will be several releases of
* Melchior FRANZ -- Friday 11 November 2005 13:38:
There have no problems been reported for plib cvs/head.
I take that back. There was also some network code committed to
the net/ directory that crashes fgfs. I assume that this will be
reverted very soon. :-(
m
Oh, and before the first points me to --fdm=ufo: I know that, of course.
--fdm=ufo and --fdm=magic can be used with any aircraft. This is actually
very useful for getting acquainted with how nav/ils instruments work.
But this is only settable from the command line, but not from fgrun,
where you
* Georg Vollnhals -- Tuesday 08 November 2005 21:00:
Melchior FRANZ schrieb:
but for now I think we can live with that.
That is ok, I think it should only be fixed before the new version gets
officially out.
You don't seem to understand: this is a very *minor*, almost cosmetic
glitch
* Georg Vollnhals -- Tuesday 08 November 2005 21:00:
[dynamic dialog components lost after them switching]
That is ok, I think it should only be fixed before the new version gets
officially out.
Oh, well. You just can't rely on what I say. I felt like fixing
that, too. Will commit later today.
* Georg Vollnhals -- Wednesday 09 November 2005 17:11:
- does not switch but after you leave the menue ('cancel') the
*main* menue is frozen (no reaction on clicks)
In my eyes something is serious when you make a legal keypress and
afterwards a big part of the programs functions don't
* Georg Vollnhals -- Wednesday 09 November 2005 17:39:
This is ok :-) - other priorities and limited time is an important factor!
After all, I am really happy with this new GUI style
And it's even fixed meanwhile, and I'm quite satisfied with the result.
(Now it even re-opens the Nasal
* Thorben -- Wednesday 09 November 2005 20:22:
i patched my code to disable dialog boxes when making screenshots, because
they were quite annoying. shouldn't we do something about that in general?
I just made two nice shots for the screenshots page, which are *supposed*
to show menu and
1 - 100 of 1324 matches
Mail list logo
