> From: Frank Olaf Sem-Jacobsen > > > > It sounds like what you are doing might be more complicated than necessary. > > How about adding a viewer instance onto the > stack of viewers for each MP aircraft (as the MP aircraft are instantiated)? > Essentially I would suggest that you use the > existing viewer class as a building block rather than making it more complex. > You could always add multiple views for each MP > aircraft if you want, and you can do things like add a property to the viewer > class that identifies MP related viewer objects in > order for your script to be able to cycle through just those. In any case > the only information you would need for this approach > would be the "current view" property that already exists. Adding new > viewers on the fly might be something that needs > to be added to the viewmgr for this approach. > > > From my (limited) viewpoint it seems that the approaches you describe > are not exactly what I'm looking for. The easiest thing to do would be > to allow the already defined views to be available for any object you > are currently looking at, be it your own aircraft, a multiplayer > aircraft, or even another AI aircraft. I'm not sure if this can be > achieved by adding additional use to the list in the view manager. > > Anyway, I have for the time being got things working using my own > "hacking" approach, adding 5 lines to viewer.cxx in > FGViewer::recalcLookAt () and doing the rest in Nasal, and I am now able > to apply the different views to the different multiplayer aircraft, > using 'v' to cycle views and 'V' to cycle aircraft. > > During this I noticed two interesting points. First, the altitude of the > multiplayer aircraft was not exported to the proper tree, even though > the latitude and longitude was. I had to fix this in my local copy to > get things to work. Second, when using a viewpoint that is relative to > any other aircraft than your own, even by defining a static view in > preferences.xml of an AI aircraft, the movement of the viewpoint St to > be unsynchronised with the object you are looking at. This results in a > view where the aircraft seems to jump around, even when it is standing > completely still. I haven't figured out yet what is the cause, perhaps > it could be some rounding error? >
Possibly, or maybe something out of sync. You want to make sure that the data being used for the model is identical to the location data being used for the view position (and not one frame apart because the MP position is updated in between). It sounds like you realize that unless you've been following on the ground and seen the ac jumping off the runway, it could easily be the viewer that is jumping. On your earlier email, you might want to, as I mentioned earlier, create separate views for the MP aircraft and swap those properties around instead. You could always identify those by adding a property to the viewer class which would flag them as MP (or a generic group property) if you wanted to be able to cyle through just the MP views. It'd be better IMO to create the addional views and focus the changes on ways of manipulating the viewer class instances as whole objects rather than trying to go in and shuffle the location properties inside the viewer class. Best, Jim -- Jim Wilson Kelco Industries PO Box 160 Milbridge, ME 04658 207-546-7989 ------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
