Curt wrote:
I did some more digging and tracked down the offending subsystem. I
will contact the developer off line and hopefully this will be a
simple fix.
It's much more enlightening if you embarass them publically. Unless
it's me, of course.
Andy
Jim Wilwon wrote:
If this is just flipping the sign why not just grep and fix all
the aircraft in CVS that specify incidence?
The files in CVS (most of them -- the ones that weren't pre-fixed
for the 0.9.9 release) specify incidence as documented, not as it
was actually implemented in code. So
Melchior FRANZ wrote:
Now the question is: should fgfs work around a broken gcc release,
when there's hope that the next version will be fixed? Or is it not
a bug,
Strictly, it's not a bug. Within a single function, it is not legal
to have two pointers of different types pointing to the same
Melchior FRANZ wrote:
Umm ... but is sizeof(float)==sizeof(int) on all supported
platforms? It's not on Atari ST, for example (IIRC). :-/
Really? I honestly thought all 68k platforms used a 32 bit int to
match the register width. Certainly all 68k gcc variants do (gcc
can't support a 16 bit
Joacim Persson wrote:
I've discovered a difference between how fgfs calls the yasim solver, and
how the yasim binary (aka yasim-test) does it. I have a -yasim.xml which
doesn't pass yasim(-test) but which fgfs accepts... ?:-P
So what is the difference? Number of iterations?
That sounds like
Harald JOHNSEN wrote:
Is it a gcc 4.0.2 (SuSE 10.0) compiler bug? tiny_xdr.cxx contains
this function;
dummy = XDR_decode_int32 (f_Val);
tmp = (float*) dummy;
return (*tmp);
This violates the strict aliasing rules that are the default for
gcc 4.x -- I believe it issues a warning to that
I've been short of time recently, but Curt is keen on getting the
twist/incidence fix into YASim in time for the next release. So I've
committed it more or less blind. :)
A quick grep through the source code gives a list of affected aircraft
configurations that I've attached below. The fix is
Steve Hosgood wrote:
It may not be universally true, but quite a few projects only start
the even/odd numbering scheme *after* they've got as far as 1.0.0
My $0.02 is that we don't want to bother with this. The purpose to
having a stable release is that third parties can build on the
product
Steve Knoblock wrote:
I'm not sure if it is possible or reasonable to implement a moving
map GPS display in NASAL and instrument XML, however, a simple text
display might be feasible.
Probably not, but you might still want to script some of the
functionality -- especially for complicated
David Luff [EMAIL PROTECTED] wrote:
Alex Romosan writes:
David Luff [EMAIL PROTECTED] writes:
Urgghh - email addy in header!
And from an unexpected source, too:
User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)
Someone needs to plonk the emacs folks, methinks. :)
Andy
Steve Knoblock wrote:
1. Will Nasal scripting give me all options to program the
push-back function (incl. playing sound files and checking
distances to other planes or to next taxi way)?
I am not sure of this, but NASAL can listen for properties and then
change properties,
Yes, Nasal
Dai Qiang wrote:
I'm wondering, if it's possible to calculate and record the pressure
distribution on all parts of a plane, e.g. gears, wings etc, when
it's landing?
Landing gear could be done fairly easily, as the force along the gear
strut is known to the FDM.
But stress on other aircraft
Brian Thomson wrote:
I'm attempting to compile FlightGear 0.9.9 on Linspire 5.0.
Compiling simgear 0.9.9 went fine
/usr/lib/libsgenvironment.so: undefined reference to
Heh, methinks you're doing a bit more than compiling there. As a
hint for the future: when you hack at your software and
Brian Thomason wrote:
Perhaps I wasn't clear enough. I should have stated that I am
attemtping to build 0.9.9 using the debian source package framework
for 0.9.8, where the .a files are converted to shared object files.
Apologies for my joking at your expense, I didn't notice your email
Melchior FRANZ wrote:
I also wanted to show the Crusader in one shot. But now that it has
been withdrawn from CVS (with very questionable arguments
Not to start a flame war, but maybe someone could bang out a quickie
YASim model for the F-8 so it can be shipped in the 0.9.9 release?
Andy
George Patterson wrote:
I have compiled and installed pre3 and noticed that I was not able
to load the b1900d
Yeah, that was me. The patch yesterday for turn off the engines when
out of fuel broke the solver for turbine aircraft. Fixed. That'll
teach me to add features right before release.
Stewart Andreason wrote:
Since Flightgear-0.9.9-pre2 compiled fine without any problems,
I was surprised to see this:
fg_init.cxx:1581: error: `setRealtimeProperty' undeclared
This is SimGear version skew. You need to use the properly
matched version of SimGear, but are probably building
After some prodding from Curt, I finally spent a few hours yesterday
tracking down the pitch down discontinuity in the Citation.
Well, I didn't find a discontinuity. I can now graph the lift curve
from a Surface (a real one, part of the real aircraft, not an isolated
test instance) and verify
Erik Hofman wrote:
Ok, I've test compiled the simgear/nasal library using gcc on IRIX
and linked it with the MIPSpro build version of FlightGear and it's
working like a charm.
great sigh of relief
Excellent. Thanks for your work, I was completely out of ideas on
this. :)
Ok, I've test
Joacim Persson wrote:
Using a Saitek stick, [..] The nasal function interpolate() works on
left wheel only, not the right wheel, making the plane twist when
brakes are applied (or released). One can see it by watching the
internal properties (controls/gear) while applying the wheel
brakes.
Joacim Persson wrote:
I've also experimented with commenting out the lines about left gear
in the joystick config file (and thus tie the button to right gear
only), to see if it had something to do with nasal per se. (as in not
being able to handle two interpolate simultaneously) But the right
Joacim Persson wrote:
Andy Ross wrote:
Which stick [...]?
Saitek Cyborg Evo
[...]
I have pinned down the exact moment in gdb when brake-right is set
to 1.0 (without a cause, so to speak), but I feel I don't have
enough knowledge about how FG is designed to come further.
What
Erik Hofman wrote:
So far I've tracked down the problem to the getMember() function
simgear/nasal/code.c. The problem starts to appear when ctx-opTop
increments from 2 to 3 in which case obj.ref.reftag isn't valid
anymore.
If it's not happening across a garbage collection, then I strongly
Erik Hofman wrote:
Is is certain that reftag is set in this case?
Yes. The modification to opTop is a pop, the stack contents have
already been pushed at that point. I just scanned through the loop
again, and don't see anywhere that an object gets copied onto the
stack incorrectly -- the only
George Patterson wrote:
/engines/engine/fuel-flow-gph[0] is shown as -0.232562 (fluctuates
rapidly)
/engines/engine/running[0] is shown as false.
Good catch. The really primitive stop support in the turbine engine
model didn't set the fuel flow value. This is fixed, such as it is.
Real
Mike Kopack wrote:
It's not so much an issue of San Fran being BAD, it's just that KSFO is
pretty far from downtown. We're talking about small slow-flying UAV's in my
project (I'm using the Piper as a surrogate), so having to take off that far
away means my demo is like 45 minutes long.
As a
Erik Hofman wrote:
Ampere K. Hardraade wrote:
A texcopy function that allows one to copy one part of the texture
to another would be useful.
Although it would be doable, one problem with this is that the textures
themselves are stored in video memory so updating them isn't as easy as
it
Drew wrote:
I have a Windows build of FlightGear, and have recently discovered
when the FlightGear window is minimized, the CPU usage jumps up to
100%. Does anyone have any idea why this happens? What can be done
to fix this?
Didn't this subject come up before? Note that CPU usage is at
Kitts wrote:
I would like to know if there is any documentation on the XML file
format used within FlightGear.
First, note that the file format is used to generate a SGPropertyNode
C++ object. So the details of how that class should drive your
understanding of the on-disk representation.
All
Kitts wrote:
Yes. But as i understand, the value of the leaf node may be read either with
getDoubleValue or getFloatValue or getStringValue etc. How does one reading
the node's value know what is the type so as to call the appropriate
method? Unless this is an internal thing meant for the low
Vivian Meazza discovered:
AIFlightPlan.cxx:69: error: passing `const std::string' as `this' argument
of `std::basic_string_CharT, _Traits, _Alloc std::basic_string_CharT,
_Traits, _Alloc::operator=(const _CharT*) [with _CharT = char, _Traits =
std::char_traitschar, _Alloc =
Martin Spott wrote:
I suspect the network stuff is coupled to the same loop as is the
screen display. Just a guess, though
It is. Everything except for terrain tile I/O is driven out of the
main loop. Probably something that should be fixed...
Note that we're going to have to start
Curtis L. Olson wrote:
I would like to make a case for non-threading from the standpoint of
simplicity. We have had (and probably still have) some extremely
subtle and extremely difficult to track bugs in our threaded tile
loader.
I don't disagree at all. Everything you say is true, and a
Harald JOHNSEN wrote:
Geoff Air wrote:
Note, Windows is not completely out of memory,
Perhaps that the system allows *only* 1GB per process ;-)
That's an interesting point. A quick google comes up with this
MSDN page that seems to indicate that XP uses a 2/2 split of
process address space,
Erik Hofman wrote:
ftp://ftp.uni-duisburg.de/FlightGear/Misc_erh/winter.tar.bz2
Karsten Krispin wrote:
I'am not able to open any of them. Winter.tar.bz2 seems to be empty, for
wt-source I need a user/pass kombination...
AJ MacLeod wrote:
Error 550 here (Not a directory) for both those files.
Ima Sudonim wrote:
I noticed that with latest CVS on mac os x, I can scroll thru views
(forward) with 'v' as many times as I like, but that 'V' (reverse)
only works 1-3 times until I reach the view that has a name ending in
'w/o yaw'.
'V' will no longer work, until I move forward in the
[ Unrelated nit: who's mail client keeps breaking this thread? ]
Ima Sudonim wrote:
The actual problem was my error: the number-views was one less
than the actual number of views. Sorry to waste bandwidth on a user
error...
OK, then the real symptom here is an interaction with the Nasal view
Martin Spott:
Norman Vine wrote:
I vote for everything being triangle based like the underlying renderer
This puts us at risk to run into huge datasets for every taxiway
junction.
What about a purely symbolic representation? Store just centerline
and width for each taxiway, and keep the
Oliver Schroeder wrote:
Andy Ross wrote:
The server only needs one socket for its whole lifetime.
Of course, but this solves only part of the problem. The main
problem is, that a a NAT router may decide to not accept
(ie. forward to the client) any packets we send back to it.
It may work
Oliver Schroeder wrote:
So the server has to reread the port from the UDP header
everytime it reseives new data from the client and recreate a
socket for it (and clse the existing one of course).
Er, no. Check the man page of sendto. :)
The server only needs one socket for its whole
Vassilii Khachaturov wrote:
The length is due to the diff inability to say that a lot of
lines were just indented right (as they were put inside an else
{} )
Use the -w argument to diff to eliminate the whitespace noise for
readability.
But regardless, don't do this. :)
Wrapping huge blocks
Jim Campbell wrote:
Anyone transmitting un-encrypted data across a world wide
internet needs to think ahead a little. Every hacker will be
rubbing their hands with glee before trying to hit you on these
ports you have just announced.
[...]
This really isn't much of an issue. The attack you
James Turner wrote:
This stops FG providing a TCP alternative to UDP on the same port,
which is something I think should be done anyway. Requiring people to
update their firewall NAT tables is not a long term approach, even
assuming the user is permittd to do such a thing
This is a
Curtis L. Olson wrote:
Oliver Schroeder wrote:
Which reminds me of another thing. Is it possible to use /dev/dsp in
a non-blocking mode?
My general opinion is I'm not sure I would like to see us overly
complicate the flightgear code to work around older hardware limitations.
[...]
This
Martin Spott wrote:
shadanim.cxx:178: error: `fmodf' undeclared (first use this function)
Well, I tried a (too) simple fix my replacing fmodf with modf which
_does_ exist on Solaris8 but [...]
These functions don't do quite this same thing, but you can implement
one instead of the other:
Ampere K. Hardraade wrote:
Curtis L. Olson wrote:
Ampere K. Hardraade wrote:
By cvs snapshots, I mean binary-snapshots packed into .deb, .rpm, etc.
If someone wants to do this, and promises to keep up on it, I can
put a link on the FG web site ...
How should the version number
Erik Hofman wrote:
I would like to see Nasal working again on IRIX. I think this is a
nice task for Andy ...
I'm out of ideas at this point. All the Nasal code I can run in
isolation (which now includes several multi-threaded stress tests that
work the garbage collector *far* more exhaustively
Martin Spott wrote:
I remembered Andy's pointer to
http://predef.sourceforge.net/preos.html and had a look at the
different ways how Solaris-specific defines are currently
implemented within FlightGear and required libraries:
[...]
SimGear/simgear/nasal/nasal.h:
defined(sun386)
Martin Spott wrote:
Have you tried on older Solaris setups than Solaris10 ? Did you use
GCC on solaris or SunStudio10?
Only Solaris 10, but with both compilers (I used the gcc Sun installs
in /usr/sfw/bin and the free download of SUNWspro). But Solaris 10 is
freely available, so if the problem
Hans-Georg Wunder wrote:
Now there three ways to go to get the panel GPL compliant:
There still seems to be a misunderstanding. The issue here is not a
minor technicality regarging open source license compatibility. It is
that this package got caught using artwork to which the author does
not
Alex Romosan wrote:
hmm, there seems to be a lot of junk in this file:
Actually, this file is in fact a gzipped tar file containing a
single TACAN_freq.txt file. Is that intended?
Andy
___
Flightgear-devel mailing list
[cc'd to flightgear-devel b/c of the internals explanation]
Jeff McBride wrote:
Andy Ross wrote:
The current helicopter FDM does not support variable rotor speed.
The spin up is entirely animation. You are flying just fine.
I don't know what FDM you are using, but when I fly the bo105
Hans-Georg Wunder wrote:
In the package there is a GPL-license.
If this is enough, then everything is OK regarding the panel.
Unfortunately, due to clear evidence of (minor, admittedly) copyright
violation, this is not enough. The issue isn't license compatibility,
it is copyright ownership.
Gabor Toth wrote:
I'm currently working on the EICAS display for 747-400, and I
would like to display TAT (Total Air Temperature) too. Is that
property available somewhere in YASim?
This is not part of the FDM, the outside air temperature comes
out of the environment code and is available in
George Patterson wrote:
lowlevel.cxx:84: error: invalid conversion from `uint64_t*'
to `long long unsigned int*'
I noticed this too. The problem is that on 64 bit systems the glibc
headers have:
typedef unsigned long int uint64_t;
Which is correct, because a long is a 64 bit type on
Martin Spott wrote:
Now as Andy promised I could have another try on big-endian machines I
decided to actually have one.
Good luck, but unfortunately it seems not to be working for Erik. I
have a pretty large test suite at this point running on sparc and ppc
without trouble, so I'm wondering
Erik Hofman wrote:
I'm leaning more and more to defining our own header files which
solves all this troubles and byte swapping stuff.
Sounds good to me. :)
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Erik pinged me on the Nasal endianness bug, which I *think* has been
fixed. It no longer occurs with the Mac test code I have, but I
didn't find a smoking gun and can't run FlightGear on that mac (shell
access only).
Anyway, please update both (!) SimGear and FlightGear CVS sources and
let me
Richard Bytheway wrote:
I am about to go away for a week, and would like to setup my
out-of-office thing in Outlook (corporate setting - no choice on
email client). However I would like to prevent it replying to this,
and other, lists that I am on. Does anyone know if this is
possible, and
Ampere K. Hardraade wrote:
Anway, I like the idea of having a dedicated online message
board for FlightGear. The primary reason why I like online
message board is that all the posts in a topic are grouped
under one thread and are sorted by dates, which is more
organized in my opinion.
This
Paul Kahler wrote:
Andy Ross wrote:
I would presume that most of these things are added not by the model
authors, but by the software they are using.
Other than the potentially embarassing information leakage (it exposes
the author's file hierarchy), this isn't really a problem.
Yes
A J MacLeod wrote:
Curtis L. Olson wrote:
What would people think of abandoning our mailing lists and
converting over to online/web-based forums?
Personally, I very much prefer mailing lists. I can quite see the
advantages of web-based forums, but I'm not convinced they outweigh
the
Oliver C. wrote:
2. The Readably of a web based forum is better.
This is a joke, right? It must be all those giant, blinking, hot pink
600x200 signature GIFs that help you tell where the text content
is. :)
Heh, to each his own. Although I will point out that most of your
complaints have more
Jim A wrote:
I have noticed there are many instances in the data directory where
developers have left explicit paths to textures, particularly in
.ac files. These paths are specific to the developer's machines,
and so will not be useful to others.
This is benign. The plib loader strips off
Melchior FRANZ wrote:
That's not a problem, but a feature. Really. After mirroring an
object you have to 'apply the rotation'. (Some key combination
with a, IIRC. Ctrl-A?) I don't know why this isn't done
automatically, but it is braindamage 'by design'.
It's hard to fix. When you mirror a
bass pumped wrote:
Andy Ross wrote:
It looks to me like you're compiling CVS FlightGear with an older
SimGear.
I did download flightgear [...] from the 'bleeding edge' link from the
website. [...] But when compiling that simgear [...] I downloaded the
0.3.8 version.
Could
Georg Vollnhals wrote:
Curtis L. Olson wrote:
There are people in the world that are actually looking at
FlightGear for building training simulators (certified and not
certified) and these people are actually quite interested in the
nit-picky details of engine operation.
well argued -
bass pumped wrote:
Actually I was asking you (indirectly I guess) if there was an error
in the bleeding edge file I downloaded from the simgear download
page. Anyway, I will try compiling that by removing the couds3d
from the solution explorer and see what happens.
I'm not sure what you
bass pumped wrote:
I'm trying to get flightgear 9.8 built in Windows. I'm using MSVC 7
for the build. I ran into the following errors from the Nasal code.
[...]
cannot convert from 'naRef (__cdecl*)(naContext,naRef,int,naRef *)' to
'naCFunction'
This looks like a version skew problem.
Vivian Meazza wrote:
YASim has not yet implemented shut down/start up controls for
gas turbines. Therefore there are none for the Hawker Hunter.
As far as I can see, there is no generic implementation possible
for turbine startup and shutdown. Everything would have to be
done specifically for
Curtis L. Olson wrote:
I was just trying to build simgear on a fresh Fedora Core 4 machine
and pulled the latest OpenAL cvs snapshot. The most recent
openal-cvs no longer includes alut for linux? Does anyone know
what's going on there? Simgear uses alut so this is a problem
(assuming I'm
Jon S. Berndt wrote:
I'd give a lot to know what these two papers are presenting! See below:
Open Source Software: Cheap Isn't Exactly Free!
B. Calloni, J. McGowan, and R. Stanley, Lockheed Martin
Corporation, Fort Worth, TX
Bazaar Meets Cathedral: Concerns About Open Source Software in
Trasca Virgil wrote:
How can I participate somehow in the developping process of
flightgear? Thanks in advance!
Use it. Fix bugs. Get into flame wars on the lists. The usual
stuff. :)
Andy
___
Flightgear-devel mailing list
Ampere K. Hardraade wrote:
Lately, my computer has been freezing on me unpredictably while I am using
FlightGear. (Note: I'm not saying FlightGear is to blame.) Normally, I just
cold boot the machine. Today however, after multiple freezes, I was too
angry to try again. I went away to do
It's not about security
jvrvez wrote:
Ok, They don't want that a GPL tools is used to interface their
network for secutity reasons (I think this is understandable)
anyway why can't we join their network with their own code?
This is a non-starter. There is simply no way to make this work,
Mathias Fröhlich wrote:
Erik Hofman wrote:
I just noticed there is even an id_t in sys/types.h on IRIX, is this
common?
I don't think so.
The only type I know that is guaranteed to be capable of storing the whole
pointer is a void*. But void* is menat to be not that pure address number
Just in case anyone else has noticed: I discovered today at work* that
the gcc 4.0.1 shipped with Fedora Core 4 miscompiles Nasal pretty
badly when the optimizer is turned on.
I'm not sure what the effect will be on FlightGear specifically, as I
haven't had time to do a build recently.
Josh Babcock wrote:
Is there a way to get controls.throttleAxis to execute for
conditions other than the throttle input changing? Specifically, I
want it to also recalculate the throttle values when the rudder
input changes. If I can do this I can implement steering with
differential engine
Gerhard Wesp wrote:
anybody knows any good source for a list of all airports and their
3-letter code (like JFK, SFO, LHR, etc.) together with its
coordinates and/or 4-letter ICAO code?
$FG_ROOT/Airports/apt.dat.gz :)
Andy
___
Flightgear-devel
Gerard Robin wrote:
Being Nvidia and X installed , i continu to search a good answer :
After many experimentations, I did not notice any change between
24bpp and 32 bpp.
There is no difference between 24 and 32 bpp on NVidia hardware. Both
of them give you a 32 bit 8:8:8:8 RGBA front and
A J MacLeod wrote:
I should perhaps mention here for those not keen on updating to the
newer nvidia drivers yet that SimGear CVS (on 1st August 2005)
_does_ compile here on nVidia 6629 and runs fine, so it's worth
trying...
You might not have the NVIDIA headers installed. Check
Gerard Robin wrote:
startup
splash-textureAircraft/harrier/harrier-splash.rgb/splash-texture
/startup
You have a splash screen image for an aircraft with no 3D model? :)
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Craig, two quick issues with your mail:
First, I notice that you are habitually starting new threads by
replying to existing, unrelated messages. Don't. This causes
problems for those of us who are using threaded mail client (I use
Mozilla Thunderbird, for example). It's confusing to be
Christian Mayer wrote:
Shouldn't you then be able to get these documents easily by the
freedom of information act?
I dunno, I've never made a FOIA request. But from what I've been led
to believe it's a very slow, bureaucratic process. And in this case
it will be complicated because of the
Josh Babcock wrote:
These require a proprietary reader from Locklizard which does not
have printing enabled.
Hrm... then apparently he has changed mechanisms. The F-51D handbook
I ordered a year or so ago is a plain encrypted PDF (with an extra
step to get it off the CD that involves an
Oliver Schroeder wrote:
Andy is, of course, right. We should not send binary data over the
wire and I think that using XDR for transmission
Binary is fine. Uncooked memory is not. :) And FWIW, XDR seems
awfully heavyweight to me. It involves a comparatively large amount
of code for things
Erik Hofman wrote:
You can always argue what would be derived work: just the modified files
or the complete package. Personally I would say the first.
Modifying a file is, pretty obviously, creating a derived work under
any reasonable interpretation. :)
There is no argument possible about the
Oliver Schroeder wrote:
Apperantly gcc under cygwin uses a different alignment for structs
than gcc under linux (I don't know which gcc version is used under
cygwin). At home I use gcc 3.3.6, and it reports:
Yet another reason why blasting raw structures out an I/O channel
(especially a
Christian Mayer wrote:
You have to use the I/O manipulators (Stroustrup: 21.4.6.2, page 633ff.)
like std::setprecision().
Compared to the fast printf syntax they are too annoying to write and
not that flexible, but they are more readable and they can be combined
to your own user defined I/O
Oliver Schroeder wrote:
2) A visibility range (Vivian called it Radar Echoing Area),
provided by aircraft model data. That way a eg. 747 can show up on
radar earlier than a cessna, making radar more real.
3) A radio transmission range, i.e. the range a client is able to reach
via radio when
Jon Berndt wrote:
Can anyone differentiate for me the concept of position as
contrasted to index in this situation?
Position is arbitrary. I think it corresponds to the order of which
the nodes were added to the parent. The only use I can think of for
this method is enumerating over all
Steve Hosgood wrote:
The position of any astronomical object relative to a viewer standing on
the planet's surface is usually given as altitude and azimuth - with
the true horizon and true North used as the references.
[...]
Additional entertainment will be provided by the fact that and code
Steve Hosgood wrote:
Solving where the planet is in its orbit for any given calendar time
is tricky.
This is just the equal area thing, right? (angular orbital velocity
goes as the inverse of the distance to the focus) I kinda-sorta
remember doing a parameterization of that in college way back
I wrote:
that, too, can be done in cartesian space and doesn't require a
nothing of sunrise/set time).
Heh, s/nothing/notion/
Most of my typos are clear from context, but that one reads like
gibberish, sorry. :)
Andy
___
Flightgear-devel mailing
Paul Surgeon wrote:
TeamSpeak doesn't have to be part of the FG package.
It's a separate program that has an API you can interface to.
Writing code that runs in the fgfs binary to interface to an API
is generally considered to be making a derivative work, for
fairly obvious reasons.
People
Paul Surgeon wrote:
What a pity as I don't know of any good replacements and writing
VOIP software is not a trivial task.
It's not so bad, really. And there certainly is open source voice
communications software out there, albeit aimed more at enterprise
applications than gamers. If the
Curt forwarded from Lukas Tinkl:
we at SUSE recently stumbled upon this problem: some of the
code contained in FlightGear contains a non-commercial lincese
which forbids us from further distributing it. The consequence
is that FlightGear wouldn't be part of the upcoming SUSE Linux
release.
Erik Hofman wrote:
Since you are already familiar with this stuff, I need the function to
calculate the sun position (in degrees or radians) above the horizon
at a certain time/lat/lon. What is this normally called:
RightAscension, Declination, Magnitude or something else?
None of the above.
And remember that a robust implementation can get big speedups by
handling
Mostyn Gale wrote:
Andy Ross wrote:
The best way to do this is actually dynamic: the server gets to
send the X most important objects to each client per update.
Importance can be defined in screen space -- think
Josh Babcock wrote:
All you have to do is drop the file in $FG_ROOT/Nasal and set
/sim/headshake/enabled='true' by the method of your choice. Then shake,
shake, shake! Be sure to read the file for known bugs, and please, send
me lots of comments.
This is really cool. If you want to try
1 - 100 of 1282 matches
Mail list logo
