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?)
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?)
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?)
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 plib/sg.h
#include simgear/scene/model/modellib.hxx
+#include simgear/scene/model/placementtrans.hxx
#include Main/globals.hxx
#include Scenery/scenery.hxx
@@ -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
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?)
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?)
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?)
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
