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 und
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, jus
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
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 o
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
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 t
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 pro
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 t
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 allways done by the server to prevent cheating.
Does
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
> >
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
> cond
> >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 la
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
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 i
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
> t
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 pro
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
prob
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.
>
> It's probably not
18 matches
Mail list logo
