Re: [Flightgear-devel] Overhauling the networking code(was:Multiplayer crashes with unknown aircrafts, any solution?)
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 network socket!) is just always a bad idea. Really, to make this work without major insanity we have to cook the output. No doubt the cygwin compiler is defaulting to the MSVC standard alignment rules. Note that you can change these at compile time under both compilers by using command line switches and/or #pragma directives, etc... Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networking code(was:Multiplayer crashes with unknown aircrafts, any solution?)
Vivian Meazza wrote: This patch does not work for Cygwin. I'm not sure if Multiplayer ever worked under Cygwin. Norman Vine did a bit of quick diagnosis last night, and came up with a cause and a fix. Apparently Linux uses 4 bytes while Cygwin uses 8 as standard. I attach Norman's diff against cvs/head. Which doesn't work for non gcc compilers (actually it probably won't work on the latest gcc compiler version either) ... Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networking code(was:Multiplayer crashes with unknown aircrafts, any solution?)
Vivian Meazza wrote: >This patch does not work for Cygwin. I'm not sure if Multiplayer ever worked >under Cygwin. > > >Norman Vine did a bit of quick diagnosis last night, and came up with a >cause and a fix. Apparently Linux uses 4 bytes while Cygwin uses 8 as >standard. > > > 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: sizeof(T_MsgHdr) + sizeof (T_POSMSG) = 120 Under cygwin it reports: sizeof(T_MsgHdr) + sizeof (T_POSMSG) = 124 >I attach Norman's diff against cvs/head. > > Norman tried to get cygwin do the same alignment which other gcc do. That's this (commented out) _attribute_ thing for, but didn't succeed. So he made an ugly hack which let you use multiplayer-mode anyway. But this hack fixes symtoms, not the cause. I don't have the right anwser, either. We must check this out and improve the used structures and their alignment. greets, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Overhauling the networking code(was:Multiplayer crashes with unknown aircrafts, any solution?)
Mathias Fröhlich > Hi, > > On Sonntag 17 Juli 2005 10:16, Vivian Meazza wrote: > > Before we do any rework of the MP code, it works as is in 0.9.8 (with > some > > bugs), but it is fundamentally broken in CVS. In cvs the received > aircraft > > are displayed close to the observer, rather than in their proper > locations. > > It works OK in 0.9.8. Melchior suggested this was something to do with > one > > of your recent updates, but I haven't rolled back to establish if this > is > > the case. > > The jitter removal patch was the cause for that. > But to be honest, that current multiplayer protocol cannot really work. > It transmits only offsets to the tile center without the information on > which > tile it is. > This was more or less sufficient for the case we had the scenery center at > the > tile center. But flying across tile bondaries was still broken ... > > I have now included a patch to the multiplyer protocoll which does: > > 1. place the 3d model into the scenery using a placement transform which > can > dynamically change its scenry center. > 2. Transmits unique position and orientation data for the 3d model. > 3. Thus breaks protocol compatibility. > :-/ > > Since the fg_server only forwards the network packets without looking into > them, this will still work with that code. > But the position data sent by a flightgear release version cannot be > understood by the current version. The same holds for the other way. > > Opinions? > > Given that it will make that usable in some way I will vote for applying. > > Anyway, this protocol is very error prone since it neither cares for > alignment > nor for endianess. I don't know of it still works for x86_64, don't talk > about the sgi's in Erik's zoo ... > :) This patch does not work for Cygwin. I'm not sure if Multiplayer ever worked under Cygwin. Norman Vine did a bit of quick diagnosis last night, and came up with a cause and a fix. Apparently Linux uses 4 bytes while Cygwin uses 8 as standard. I attach Norman's diff against cvs/head. Btw, if there any other Cygwin users still out there - I've just updated my copy of Cygwin. The latest version gives a worthwhile improvement in both file reading and in frame rate. Vivian mpmessages.diff Description: Binary data ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networking code(was:Multiplayer crashes with unknown aircrafts, any solution?)
Mathias Fröhlich wrote: >What is missing is a clear architecture indenpendent definition of the storage >layout >Also a 'protocol version' field in the message header will be a good idea IMO. >That way clients could distinguish if and how they should look at that binary >chunk. > > The version field is a good idea. And I have another suggestion. There should be a "info" packet, containing details of the client. I'm not sure what information should be sent to call the packet "complete", but I have some ideas of what should be included anyway: 1) The aircraft (name) a client is using (it isn't nessecary to send this information with every packet) 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 sending (voice) messages 4) A radio receive range, i.e. the range a client is able to receive messages from. This may also be aircraft specific, not sure about that. 5) the frequency a client is listening to (erm, there are two listening frequencies, right?) 6) the sending frequency of a client There is probably more information needed. However, the network protocol has to make sure that this information is received by others, that means there should be some confirmation mechanism on received packets, at least for these info packets. My suggestion for this is: 1) The info packet contains random "packet number" 2) The sender resends the packet until it receives an "acknoledge"-packet from the receiver (another client or fg_server), containing only the "packet number" and a string "ackloledged". An info packet must be sent if any information is changed, e.g. a client switches frequencies or whatever. Opinions? Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networking code (was:Multiplayer crashes with unknown aircrafts, any solution?)
Mathias Fröhlich wrote: >The jitter removal patch was the cause for that. >But to be honest, that current multiplayer protocol cannot really work. >It transmits only offsets to the tile center without the information on which >tile it is. >This was more or less sufficient for the case we had the scenery center at the >tile center. But flying across tile bondaries was still broken ... > > It was a long trip for me to figure out that the transmitted position is only tile-local. I'm very happy that I now get global data and hence can calculate distance correctly ;) >Since the fg_server only forwards the network packets without looking into >them, this will still work with that code. >But the position data sent by a flightgear release version cannot be >understood by the current version. The same holds for the other way. > > > As long as it is documented, it's ok. The network code badly needs changes which can't be done without braking compatibility. >Anyway, this protocol is very error prone since it neither cares for alignment >nor for endianess. I don't know of it still works for x86_64, don't talk >about the sgi's in Erik's zoo ... >:) > > What about converting the data to network byte order before sending, and converting it back to host order when receiving? (using ntohl(3) and htonl(3) on the buffer). regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networking code (was:Multiplayer crashes with unknown aircrafts, any solution?)
On July 24, 2005 01:08 pm, Mathias Fröhlich wrote: > Since the fg_server only forwards the network packets without looking into > them, this will still work with that code. It would appear that fg_server is doing more than merely forwarding network packets now. Those who are using your patch are getting the following messages: FGMultiplayRxMgr::MP_ProcessData - Position message received with insufficient data Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networking code(was:Multiplayer crashes with unknown aircrafts, any solution?)
On Sonntag 24 Juli 2005 19:51, Vivian Meazza wrote:
> That's got to be better than broken. Shame it's not backward compatible
> though. Let's get it into cvs then we can move forward.
>
> Norman Vine came up with some modified code over on the IRC channel:
>
> "globals->get_multiplayer_tx_mgr()->
> SendMyPosition(globals->get_aircraft_model()->get3DModel()->
> get_POS() +
> globals->get_scenery ()->get_center() );
> I think that this is probably what wants to be sent in
> FGMultiplay::process() {"
>
> Is this any good to us? Or does it conflict with your diff?
From what you tell here, Norman follows the same idea like my patch does.
I don't know how he implemented that idea.
But what I did, uses doubles for the position (with floats you will have
roundoff in the magnitude of 1e-7*6e6 \approx 1 m in the multiplayer's
positions).
And I use quaternions for the orientations, which is more compact
representation (4 floats) than sending the whole transform matrix.
What is missing is a clear architecture indenpendent definition of the storage
layout
Also a 'protocol version' field in the message header will be a good idea IMO.
That way clients could distinguish if and how they should look at that binary
chunk.
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Overhauling the networking code(was:Multiplayer crashes with unknown aircrafts, any solution?)
Mathias Fröhlich
>
> On Sonntag 17 Juli 2005 10:16, Vivian Meazza wrote:
> > Before we do any rework of the MP code, it works as is in 0.9.8 (with
> some
> > bugs), but it is fundamentally broken in CVS. In cvs the received
> aircraft
> > are displayed close to the observer, rather than in their proper
> locations.
> > It works OK in 0.9.8. Melchior suggested this was something to do with
> one
> > of your recent updates, but I haven't rolled back to establish if this
> is
> > the case.
>
> The jitter removal patch was the cause for that.
> But to be honest, that current multiplayer protocol cannot really work.
> It transmits only offsets to the tile center without the information on
> which
> tile it is.
> This was more or less sufficient for the case we had the scenery center at
> the
> tile center. But flying across tile bondaries was still broken ...
>
> I have now included a patch to the multiplyer protocoll which does:
>
> 1. place the 3d model into the scenery using a placement transform which
> can
> dynamically change its scenry center.
> 2. Transmits unique position and orientation data for the 3d model.
> 3. Thus breaks protocol compatibility.
> :-/
>
> Since the fg_server only forwards the network packets without looking into
> them, this will still work with that code.
> But the position data sent by a flightgear release version cannot be
> understood by the current version. The same holds for the other way.
>
> Opinions?
>
> Given that it will make that usable in some way I will vote for applying.
>
> Anyway, this protocol is very error prone since it neither cares for
> alignment
> nor for endianess. I don't know of it still works for x86_64, don't talk
> about the sgi's in Erik's zoo ...
That's got to be better than broken. Shame it's not backward compatible
though. Let's get it into cvs then we can move forward.
Norman Vine came up with some modified code over on the IRC channel:
"globals->get_multiplayer_tx_mgr()->
SendMyPosition(globals->get_aircraft_model()->get3DModel()->
get_POS() +
globals->get_scenery ()->get_center() );
I think that this is probably what wants to be sent in
FGMultiplay::process() {"
Is this any good to us? Or does it conflict with your diff?
Vivian
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networking code (was:Multiplayer crashes with unknown aircrafts, any solution?)
Hi,
On Sonntag 17 Juli 2005 10:16, Vivian Meazza wrote:
> Before we do any rework of the MP code, it works as is in 0.9.8 (with some
> bugs), but it is fundamentally broken in CVS. In cvs the received aircraft
> are displayed close to the observer, rather than in their proper locations.
> It works OK in 0.9.8. Melchior suggested this was something to do with one
> of your recent updates, but I haven't rolled back to establish if this is
> the case.
The jitter removal patch was the cause for that.
But to be honest, that current multiplayer protocol cannot really work.
It transmits only offsets to the tile center without the information on which
tile it is.
This was more or less sufficient for the case we had the scenery center at the
tile center. But flying across tile bondaries was still broken ...
I have now included a patch to the multiplyer protocoll which does:
1. place the 3d model into the scenery using a placement transform which can
dynamically change its scenry center.
2. Transmits unique position and orientation data for the 3d model.
3. Thus breaks protocol compatibility.
:-/
Since the fg_server only forwards the network packets without looking into
them, this will still work with that code.
But the position data sent by a flightgear release version cannot be
understood by the current version. The same holds for the other way.
Opinions?
Given that it will make that usable in some way I will vote for applying.
Anyway, this protocol is very error prone since it neither cares for alignment
nor for endianess. I don't know of it still works for x86_64, don't talk
about the sgi's in Erik's zoo ...
:)
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
Index: src/MultiPlayer/mpmessages.hxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/MultiPlayer/mpmessages.hxx,v
retrieving revision 1.2
diff -u -r1.2 mpmessages.hxx
--- src/MultiPlayer/mpmessages.hxx 26 Mar 2003 14:06:51 - 1.2
+++ src/MultiPlayer/mpmessages.hxx 24 Jul 2005 17:07:25 -
@@ -39,7 +39,8 @@
// Message identifiers
#define CHAT_MSG_ID 1
-#define POS_DATA_ID 2
+#define UNUSABLE_POS_DATA_ID 2
+#define POS_DATA_ID 3
#define MAX_CALLSIGN_LEN 10
/** Header for use with all messages sent */
@@ -80,7 +81,8 @@
char sModel[MAX_MODEL_NAME_LEN];
/** Position data for the aircraft */
-sgMat4 PlayerPos;
+sgdVec3 PlayerPosition;
+sgQuat PlayerOrientation;
} T_PositionMsg;
Index: src/MultiPlayer/mpplayer.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/MultiPlayer/mpplayer.cxx,v
retrieving revision 1.9
diff -u -r1.9 mpplayer.cxx
--- src/MultiPlayer/mpplayer.cxx 15 Jul 2005 09:45:57 - 1.9
+++ src/MultiPlayer/mpplayer.cxx 24 Jul 2005 17:07:25 -
@@ -53,6 +53,7 @@
#include
#include
+#include
#include
#include
@@ -140,6 +141,7 @@
// Disconnect the model from the transform, then the transform from the scene.
m_ModelTrans->removeKid(m_Model);
+globals->get_scenery()->unregister_placement_transform(m_ModelTrans);
globals->get_scenery()->get_aircraft_branch()->removeKid( m_ModelTrans);
// Flush the model loader so that it erases the model from its list of
@@ -164,12 +166,14 @@
* Description: Updates position data held for this player and resets
* the last update time.
**/
-void MPPlayer::SetPosition(const sgMat4 PlayerPosMat4) {
+void MPPlayer::SetPosition(const sgQuat PlayerOrientation,
+ const sgdVec3 PlayerPosition) {
// Save the position matrix and update time
if (m_bInitialised) {
-sgCopyMat4(m_ModelPos, PlayerPosMat4);
+sgdCopyVec3(m_ModelPosition, PlayerPosition);
+sgCopyVec4(m_ModelOrientation, PlayerOrientation);
time(&m_LastUpdate);
m_bUpdated = true;
}
@@ -187,16 +191,16 @@
MPPlayer::TPlayerDataState eResult = PLAYER_DATA_NOT_AVAILABLE;
-sgCoord sgPlayerCoord;
-
if (m_bInitialised && !m_bLocalPlayer) {
if ((time(NULL) - m_LastUpdate < TIME_TO_LIVE)) {
// Peform an update if it has changed since the last update
if (m_bUpdated) {
// Transform and update player model
-sgSetCoord( &sgPlayerCoord, m_ModelPos);
-m_ModelTrans->setTransform( &sgPlayerCoord );
+sgMat4 orMat;
+sgMakeIdentMat4(orMat);
+sgQuatToMatrix(orMat, m_ModelOrientation);
+m_ModelTrans->setTransform(m_ModelPosition, orMat);
eResult = PLAYER_DATA_AVAILABLE;
@@ -247,7 +251,7 @@
void MPPlayer::LoadModel(void) {
-m_ModelTrans = new ssgTransform;
+m_ModelTrans = new ssgPlacementTransform;
// Load the model
m_Model = globals->get_model_lib()->load_
RE: [Flightgear-devel] Overhauling the networking code (was:Multiplayer crashes with unknown aircrafts, any solution?)
Mathias > Hi, > > this is a very good idea IMO. > I was thinking about a very similar approach but never had the time and > not > yet the actual need to follow that. > > If you do something like that, you might take care for the MATHWORKS guys > which use the network code like it is at the moment. So one will need > probably some compatibility mode here. > Before we do any rework of the MP code, it works as is in 0.9.8 (with some bugs), but it is fundamentally broken in CVS. In cvs the received aircraft are displayed close to the observer, rather than in their proper locations. It works OK in 0.9.8. Melchior suggested this was something to do with one of your recent updates, but I haven't rolled back to establish if this is the case. Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
