Am Friday 15 July 2005 23:34 schrieb Ampere K. Hardraade:
I think it will be more flexible if the networking portion of FlightGear
can be modified to exchange properties. For starter, the
nodes /accelerations, /positions, and /surface-positions can be exchanged
among users. Properties under
Ampere K. Hardraade wrote:
I think it will be more flexible if the networking portion of
FlightGear can be modified to exchange properties. For
starter, the nodes /accelerations, /positions, and
/surface-positions can be exchanged among users. Properties
under /accelerations can allow one
Ampere K. Hardraade wrote:
How about creating root-less nodes to act as seperated property
trees for these aircrafts? This way, it will be easier to fool
the animation files of these aircrafts into taking the proper
values.
Yes, exactly. They don't need to be rootless, just detached from
Andy Ross wrote:
Ampere K. Hardraade wrote:
How about creating root-less nodes to act as seperated property
trees for these aircrafts? This way, it will be easier to fool
the animation files of these aircrafts into taking the proper
values.
Yes, exactly. They don't need to be rootless,
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
Ampere K. Hardraade wrote:
[...]As to /surface-positions, the properties inside this node can
allow one to see
the animations of others correctly.
Displaying an animated aircraft won't be easy. Animation code in xml
file is refering properties from
the FG property tree (ie the user
Harald JOHNSEN
Ampere K. Hardraade wrote:
[...]As to /surface-positions, the properties inside this node can
allow one to see
the animations of others correctly.
Displaying an animated aircraft won't be easy. Animation code in xml
file is refering properties from
the FG property
Vivian Meazza wrote:
Multiplayer models are already animated - gear goes up/down
correctly. The
problem is that all models are controlled by the receiving player, not the
transmitting one. Shouldn't be too hard to fix.
Is this the right approach? Could we include e.g. the gear up
command in a
Harald JOHNSEN
Vivian Meazza wrote:
Multiplayer models are already animated - gear goes up/down
correctly. The
problem is that all models are controlled by the receiving player, not
the
transmitting one. Shouldn't be too hard to fix.
Is this the right approach? Could we include
Very good idea, and weather. I don't suppose clouds would be easy?
Vivian
Cloud movement is based on wind direction and speed so it should be the
same at all time if the
initial situation is the same. To construct the initial situation I
think it's enought to send the cloud layer
On Sunday 17 July 2005 16:55, Vivian Meazza wrote:
Harald JOHNSEN
I guess the first player will set the environment for all subsequent
players, or would the server have some say in this?
Such things should be allways done by the server to prevent cheating.
How would the initial
conditions
Vassilii Khachaturov
Very good idea, and weather. I don't suppose clouds would be easy?
Vivian
Cloud movement is based on wind direction and speed so it should be the
same at all time if the
initial situation is the same. To construct the initial situation I
think it's enought
On Sunday 17 July 2005 20:20, Vivian Meazza wrote:
Oliver C
On Sunday 17 July 2005 16:55, Vivian Meazza wrote:
Harald JOHNSEN
I guess the first player will set the environment for all subsequent
players, or would the server have some say in this?
Such things should be
On July 17, 2005 08:08 am, Harald JOHNSEN wrote:
receiver property tree using the c172p model
root0\
|-position/*
|-surface/*
|-other properties
'player' 1 property subtree in receiver memory using a Concorde model
root1\
|-position1/*
|-surface1/*
|-eof
'player' 2 property subtree
Ampere K. Hardraade wrote:
On July 15, 2005 05:41 am, Erik Hofman wrote:
Looking at the Multiplayer code I can see this code can use a good
overhaul anyway. It needs to adapt the SGSubsystem style and use the
AIModel code to display the models, which will also allow it to show up
on the radar.
Vivian Meazza wrote:
Harald JOHNSEN
Ampere K. Hardraade wrote:
[...]As to /surface-positions, the properties inside this node can
allow one to see
the animations of others correctly.
Displaying an animated aircraft won't be easy. Animation code in xml
file is refering properties from
the
16 matches
Mail list logo
