Status update on Multiplayer.
We got our multiplayer-deamon up and running SunOS 4.7
and will port to current codebase to Linux (RH 7.3)
and Cygwin(or VC++ 7) somewhere next week.
Next step will be defining the protocols. Basic
outline for first-time handshake should be finished by
wednesday.
ace project [EMAIL PROTECTED] wrote:
First question is what do you have in mind when you mean multiplayer. Supporting
for example combat multiplay vs. GA multiplay vs. FSD multiplay are very
different.
For something like FSD, TCP is required. For something like combat multiplay,
UDP is
--- Billy Verreynne [EMAIL PROTECTED] wrote:
ace project [EMAIL PROTECTED] wrote:
First question is what do you have in mind when you
mean multiplayer. Supporting
for example combat multiplay vs. GA multiplay vs.
FSD multiplay are very
different.
For something like FSD, TCP is
ace project [EMAIL PROTECTED] wrote:
We already decided on UDP, because we want to play
over a unreliable latency connection (Internet). TCP
has never been a option.
The only real problem with using UDP is when dealing with state or event data.
For example, this guy have a missile lock on
On Fri 12. July 2002 09:15, you wrote:
Status update on Multiplayer.
We got our multiplayer-deamon up and running SunOS 4.7
and will port to current codebase to Linux (RH 7.3)
and Cygwin(or VC++ 7) somewhere next week.
Next step will be defining the protocols. Basic
outline for first-time
The motion hardware has 2 degrees of freedom. Last night we had a
discussion on
what data to use from the sim (angular accelerations, velocities,
pitch, roll
etc.) and how to apply it to the motion hardware.
There might be some useful documents here:
Jon Berndt [EMAIL PROTECTED] wrote:
There might be some useful documents here:
snipped
Many thanks Jon!
--
Billy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
You might also search here:
http://techreports.larc.nasa.gov/ltrs/ltrs.html
Specifically:
http://techreports.larc.nasa.gov/ltrs/PDF/1999/aiaa/NASA-aiaa-99-4328.pdf
Jon
smime.p7s
Description: application/pkcs7-signature
Jon Berndt wrote:
The motion hardware has 2 degrees of freedom. Last night we had a
discussion on
what data to use from the sim (angular accelerations, velocities,
pitch, roll
etc.) and how to apply it to the motion hardware.
Also, if I recall correctly, the space shuttle motion
Jon Berndt [EMAIL PROTECTED] wrote:
Specifically:
http://techreports.larc.nasa.gov/ltrs/PDF/1999/aiaa/NASA-aiaa-99-4328.pdf
Already ran across that one Jon using that search URL you specified.
Great minds use search criteria alike? :-)
Thanks again.
--
Billy
Er ... to drive the motion base's position, or its velocity, or
its acceleration ... ?
- Julian
That's a good question.
My initial *guess* would be to drive the same thing on the motion base,
that is, aircraft da/dt drives motion base da/dt, with a constant effort
at trying to re-center the
--- Billy Verreynne [EMAIL PROTECTED] wrote:
ace project [EMAIL PROTECTED] wrote:
The only real problem with using UDP is when dealing
with state or event data.
...
UDP simply does
not gurantee delivery. And there are times I do not
want to send and pray.
UDP can be made reliable with a
ace project wrote:
All packets will (hopefully) support compression
using
zlib.
At software level? I would be hesitant to do this
myself. Compression and
decompression can become an overhead and result in
being the bottleneck, instead
of network latency. As a multiplay
Martin Dressler wrote:
On Fri 12. July 2002 09:15, you wrote:
Status update on Multiplayer.
We got our multiplayer-deamon up and running SunOS 4.7
and will port to current codebase to Linux (RH 7.3)
and Cygwin(or VC++ 7) somewhere next week.
Next step will be defining the
ace project wrote:
--- Billy Verreynne [EMAIL PROTECTED] wrote:
All packets will (hopefully) support compression
using
zlib.
At software level? I would be hesitant to do this
myself. Compression and
decompression can become an overhead and result in
being the bottleneck, instead
of network
Christian Mayer wrote:
I don't know if zipped packages help much for the kind of data you are
sending. You can only compress redundant information
Amen. He speaks the truth.
But note that there is lots of opportunity for compression here; it's
just that dumb general-purpose algorithms like
FYI
http://virtualcities.ida.org/virtualcities/virtualcities.html
These models are available for free
see link to developers den
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Erik Hofman wrote:
Which reminds me. About two years ago I had some interrest in a *very
small* real-time compression algorithm I saw on freshmeat.net
It has absolute real time (small memory footprint) decompression and
semi-realtime compression (if I recall all that correclty).
Ah, here
Andy Ross writes:
Christian Mayer wrote:
I don't know if zipped packages help much for the kind of data you are
sending. You can only compress redundant information
Amen. He speaks the truth.
But note that there is lots of opportunity for compression here; it's
just that dumb
Norman Vine wrote:
Andy Ross writes:
Christian Mayer wrote:
I don't know if zipped packages help much for the kind of data you are
sending. You can only compress redundant information
Amen. He speaks the truth.
I had to proofe it as homework once :)
But note that there is lots of
Hi All,
Just wondering if anyone else uses this stick successfully?
It works perfectly here under windoz but after *hours* of changing the
.fgfsrc and starting and stopping fg for each change, I am getting a
little discouraged.
Thanks take care, Vikki.
--
Victoria Welch, WV9K/7,
Victoria Welch [EMAIL PROTECTED] said:
Hi All,
Just wondering if anyone else uses this stick successfully?
It works perfectly here under windoz but after *hours* of changing the
.fgfsrc and starting and stopping fg for each change, I am getting a
little discouraged.
I'm not, but
Check out 'minilzo' for fast lightweight compression.
My testing shows that compression is about 1/8 memcpy speed
and decompression is about 1/3 memcpy speed. And, it compresses
tight.
http://www.oberhumer.com/opensource/lzo/
Regards.
Mark K Vallevand
Fat, dumb and happy. 2 out of 3 ain't
On Fri, 2002-07-12 at 09:34, Christian Mayer wrote:
Martin Dressler wrote:
On Fri 12. July 2002 09:15, you wrote:
Status update on Multiplayer.
We got our multiplayer-deamon up and running SunOS 4.7
and will port to current codebase to Linux (RH 7.3)
and Cygwin(or VC++ 7)
Hello Jim,
Thanks for the response!
On Fri, 2002-07-12 at 11:32, Jim Wilson wrote:
Victoria Welch [EMAIL PROTECTED] said:
Hi All,
Just wondering if anyone else uses this stick successfully?
It works perfectly here under windoz but after *hours* of changing the
.fgfsrc and
Victoria Welch [EMAIL PROTECTED] said:
All loaded, I have to load joydev manually, but all are loaded and
catting js0 results in changing garbage on the screen.
Good sign.
If it then works in jstest, then all you need to do is make a config file that
maps the axes and buttons to
http://virtualcities.ida.org/virtualcities/virtualcities.html
Finally! I asked them nicely to make them available for people like us.
I think it would be a good idea to get involved, convert one of their
cities into TerraGear format and make it available to both them and us.
Why ?
* It
Hi Jim,
Thanks for the response!
Look at that doc file. If you aren't into learning the xml configuration and
just want to see if something will work, just get the plib cvs (plib.sf.net)
and more than likely you'd have ailerons and elevators with the default config
(Umm...waiting for a
28 matches
Mail list logo
