Re: [Flightgear-devel] Re: [BUG] bo105 model as an AI representing another player
On Sunday 19 March 2006 16:51, Mathias Fröhlich wrote: > On Sunday 19 March 2006 16:37, Melchior FRANZ wrote: > > * Vassilii Khachaturov -- Sunday 19 March 2006 16:22: > > > Yes, you are right, no /rotors/... there. Can you (or whatever other > > > patching powers that be that are responsible for the MultiPlayer/... > > > stuff (Mathias?)) please add the helicopter properties > > > > I let the MP masters do that if they feel like it. I just wonder what > > we are going to do with n1 and n2 for 10 turbines. Will these 20 > > properties somehow affect MP animations? Ideally, it should be up to > > the aircraft to decide which properties it sends, but it looks as if > > this is planned. > > Yes, I fully agree. And yes. It's exactly what I want to achieve: letting the aircraft decide what properties to send. But first of all, we have to change the used protocol. > > That n* where just there when I got the prevous attempts to transmit some > properties. > > I did not (yet?) get to the point where this is negotiated with the > aircraft configuration. > There is also something missing for that. Oliver Schröder had some very > nice ideas and partly code for the protocol together with his server > implementation. So the protocol would negotiate property-id's with the > feeder flightgear instance. That way we could even eliminate this current > 'hardcoding'. > > I was waiting for his code to integrate this stuff then. Sadly I have not > heared much from him during the past few weeks. I thought it would be best practice to take current state as is. The comming changes are quite big (especially the packet confirmation handling). > Also we have since a few weeks again and again a 'pending release' , I > wanted initially just have a more or less stable packet format established > before we push out a next release. It was because of this pending release why I didn't put any preasure on this. If you expect any real gains from it, I could provide a buffer class where we can simply write() and read() data from/to without being troubled about what fits into a buffer (implementing a send- and a receive-queue). It's not really finished right now, but usable. However, packet-confirmation is not handled at all, yet). I can focus my time on this, and provide usable code this week. regards, Oliver --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: [BUG] bo105 model as an AI representing another player
* Mathias Fröhlich -- Sunday 19 March 2006 16:51: > I wanted initially just have a more or less stable packet format > established before we push out a next release. That's understandable. > I wonder why the bo is not able to fly without properties :). Oh, it *is* flyable. Too well in fact. And that's the problem. The real one wouldn't fly with only one rotor blade. (Although one-blade helicopters exist -- the Bo102 and the Bo103 had only one!) (BTW: it's not only one blade, but all four blades on the same spot.) > Seriously: Which ones do you need? Oh, *lots*. It really depends on how many are acceptable. There's only one helicopter, so it should probably not use up too many. Crucial are: rotors/main/rpm rotors/tail/rpm This will get standing rotor, rotor disk and sound(?) right. But it won't move the single (non-rotor-disk) blades, and won't bend/flap them (looks cheesy on parked/starting helicopter). For this we'd currently need: rotors/main/blade1_pos rotors/main/blade2_pos rotors/main/blade3_pos rotors/main/blade4_pos rotors/main/blade1_flap rotors/main/blade2_flap rotors/main/blade3_flap rotors/main/blade4_flap rotors/tail/blade1_pos rotors/tail/blade2_pos For MP we should really only transmit blade position, flap, and incidence angle once and use that for all blades, but for that we'd need nasal, and MP aircraft don't have nasal yet (except on my disk, and only once per MP model, not per instance). And the question is if the blade positions are transmitted often enough at all to look acceptable. Nice to have but only about as necessary as the tail hook would be the doors, and the variant. But those depend very much on the model and wouldn't be usable by other helicopters, so I'd leave that for now. These are mostly cosmetics and not really worth it: rotors/main/blade1_incidence rotors/main/blade2_incidence rotors/main/blade3_incidence rotors/main/blade4_incidence rotors/tail/blade1_incidence rotors/tail/blade1_incidence Note also, that the rotor names depend on the bo105 settings and aren't necessarily usable by other helicopters. But this is good enough until the aircraft are responsible for their properties. In other words, the first two groups would be nice for now, but could be reduced to just 5 with some nasal support (which we don't have currently). m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [BUG] bo105 model as an AI representing another player
On Sunday 19 March 2006 16:37, Melchior FRANZ wrote: > * Vassilii Khachaturov -- Sunday 19 March 2006 16:22: > > Yes, you are right, no /rotors/... there. Can you (or whatever other > > patching powers that be that are responsible for the MultiPlayer/... > > stuff (Mathias?)) please add the helicopter properties > > I let the MP masters do that if they feel like it. I just wonder what > we are going to do with n1 and n2 for 10 turbines. Will these 20 > properties somehow affect MP animations? Ideally, it should be up to > the aircraft to decide which properties it sends, but it looks as if > this is planned. Yes, I fully agree. That n* where just there when I got the prevous attempts to transmit some properties. I did not (yet?) get to the point where this is negotiated with the aircraft configuration. There is also something missing for that. Oliver Schröder had some very nice ideas and partly code for the protocol together with his server implementation. So the protocol would negotiate property-id's with the feeder flightgear instance. That way we could even eliminate this current 'hardcoding'. I was waiting for his code to integrate this stuff then. Sadly I have not heared much from him during the past few weeks. Also we have since a few weeks again and again a 'pending release' , I wanted initially just have a more or less stable packet format established before we push out a next release. Melchior, I wonder why the bo is not able to fly without properties :). Seriously: Which ones do you need? greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: [BUG] bo105 model as an AI representing another player
* Melchior FRANZ -- Sunday 19 March 2006 16:37: > I let the MP masters do that if they feel like it. I just wonder what > we are going to do with n1 and n2 for 10 turbines. Ahh, sound and exhaust plume. But somehow I think rotors would have more impact. :-] m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: [BUG] bo105 model as an AI representing another player
* Vassilii Khachaturov -- Sunday 19 March 2006 16:22: > Yes, you are right, no /rotors/... there. Can you (or whatever other > patching powers that be that are responsible for the MultiPlayer/... > stuff (Mathias?)) please add the helicopter properties I let the MP masters do that if they feel like it. I just wonder what we are going to do with n1 and n2 for 10 turbines. Will these 20 properties somehow affect MP animations? Ideally, it should be up to the aircraft to decide which properties it sends, but it looks as if this is planned. m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [BUG] bo105 model as an AI representing another player
> Multiplayer is only for airplanes, not for helicopters. Just look :-)) > at the list of transferred properties in MultiPlayer/multiplaymgr.cxx. > No rotors there -- nothing helicopter related, but lots of other stuff. Yes, you are right, no /rotors/... there. Can you (or whatever other patching powers that be that are responsible for the MultiPlayer/... stuff (Mathias?)) please add the helicopter properties to the list in the CVS? Note that, following the last packet format change, the server will not have to be updated when you do it. V. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: [BUG] bo105 model as an AI representing another player
* Vassilii Khachaturov -- Sunday 19 March 2006 02:14: > http://www.tarunz.org/~vassilii/Images/fg/bo105-ai-1blade.jpg > features a bo105 (with Julien at the controls) which flies > smoothly, despite being 1-bladed and with a miraculous > shadow attached (I believe the shadow is a known thing, but > I'm unsure about the blades). Multiplayer is only for airplanes, not for helicopters. Just look at the list of transferred properties in MultiPlayer/multiplaymgr.cxx. No rotors there -- nothing helicopter related, but lots of other stuff. m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
