Hi,
On Thursday 08 October 2009 17:29:21 James Turner wrote:
Related to the new route-manager: I could very easily define a string
property which contains a plain text summary of the filed flight-plan.
What is the magic required to expose that string (which be 200 or 400
bytes, I guess,
Hi,
On Thursday 08 October 2009 22:09:40 Martin Spott wrote:
If bandwidth is not a matter, then you'd probably want to jump on the
HLA train and join the CERTI/VirtualAir effort. They're offering
everything like subscribing to attributes and the such yet I have
to state that reduced
On Friday 09 October 2009 00:21:11 James Turner wrote:
On 8 Oct 2009, at 23:05, Vivian Meazza wrote:
This, or something very like it, is a long outstanding proposal that
never
quite made it. No one got a round tuit for it I guess. That said, a
minute
delay on event-driven
On 9 Oct 2009, at 07:30, Oliver Schroeder wrote:
Currently I'm trying to get everything working. I therefor I have
written a
pseudo client, called mpdummy. The code is currently not fully
functional, as
it is work in progress. I try my best to write some documentation of
the
current
James Turner wrote:
There's quite a lot of improvements that could be made to higher
levels of MP, if arbitrary properties could be synchronised over MP :)
I once played with the idea of assigning 32-bit id's to property names
(and make the unique and consistent across clients) and a simple
Oliver Schroeder wrote:
On Friday 09 October 2009 00:21:11 James Turner wrote:
On 8 Oct 2009, at 23:05, Vivian Meazza wrote:
This, or something very like it, is a long outstanding proposal that
never
quite made it. No one got a round tuit for it I guess. That said, a
minute
On Friday 09 October 2009 14:47:14 Vivian Meazza wrote:
This all sounds very exciting. I'm usually available for testing (on
Windows) - remember the hassle we had with linux/Windows and MP in the past?
We will not get into such trouble again. But... ;)
I have ripped all plib networking code
Erik Hofman wrote:
I once played with the idea of assigning 32-bit id's to property names
(and make the unique and consistent across clients) and a simple push
and pull protocol.
As an interesting side effect, assigning pre-defined ID's to every
property would require all involved aircraft
On Thu, 8 Oct 2009, James Turner wrote:
Related to the new route-manager: I could very easily define a string
property which contains a plain text summary of the filed flight-plan.
What is the magic required to expose that string (which be 200 or 400
bytes, I guess, depending on how many
On 8 Oct 2009, at 18:08, Anders Gidenstam wrote:
The way the MP protocol is done now you really really do not want to
do
that by creating a new MP enabled string property and put the flight-
plan
in it. Not only is the string encoding horribly inefficient (a 32bit
word
per character)
The way the MP protocol is done now you really really do not want to do
that by creating a new MP enabled string property and put the flight-plan
in it. Not only is the string encoding horribly inefficient (a 32bit word
per character) but it would also be sent in each and every packet.
Wow,
On Thu, 8 Oct 2009, James Turner wrote:
That sounds bad :)
It is, but in my experience there is no core developer feeling
particularly responsible for the MP subsystem - most of the few patches
that has been submitted in the past years have disappeared into the
mailing list archive without
James Turner wrote:
There's quite a lot of improvements that could be made to higher
levels of MP, if arbitrary properties could be synchronised over MP :)
As far as _I_ remember, the current state of the protocol was _not_
designed for having everyone dump arbitrary data to the crowd but
Anders Gidenstam wrote
On Thu, 8 Oct 2009, James Turner wrote:
That sounds bad :)
It is, but in my experience there is no core developer feeling
particularly responsible for the MP subsystem - most of the few patches
that has been submitted in the past years have disappeared into the
On 8 Oct 2009, at 21:37, Vivian Meazza wrote:
Way back in the early iterations of MP we had 2 sorts of messages -
those
which were transmitted on every cycle, and those which were
transmitted on
change of data. The trouble with that is with clients joining and
leaving,
it is hard to
On Thu, 8 Oct 2009, Vivian Meazza wrote:
Way back in the early iterations of MP we had 2 sorts of messages - those
which were transmitted on every cycle, and those which were transmitted on
change of data. The trouble with that is with clients joining and leaving,
it is hard to ensure that
On 8 Oct 2009, at 21:54, Anders Gidenstam wrote:
Going in that direction could be a feasible way to
reduce the bandwidth consumption, though.
One other observation - there's several unused SGProperty flags
(besides ARCHIVABLE) - it might make sense to add a 'shared' or
'published' flag,
James wrote
-Original Message-
From: James Turner [mailto:zakal...@mac.com]
Sent: 08 October 2009 22:06
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Exposing a property over MP
On 8 Oct 2009, at 21:54, Anders Gidenstam wrote:
Going in that direction
On 8 Oct 2009, at 23:05, Vivian Meazza wrote:
This, or something very like it, is a long outstanding proposal that
never
quite made it. No one got a round tuit for it I guess. That said, a
minute
delay on event-driven properties is probably too much.
Well if it's 30 seconds, I think a
19 matches
Mail list logo
