Jim Wilson wrote:
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. If this doesn't sound like what you are looking for, then perhaps you would want to do something like create a class that is part of the MP system that essentially keeps track of the location data for all the MP aircraft and ties the "currently watcheed" MP aircraft's location to a common property tree location. This class's only job would be to keep track of which is the currently watched MP aircraft, and then for each cycle, copy the location data for that aircraft to that common property location for which a view (or collection of views) is defined. I've been saying "class" but I'm sure you could implement the whole thing in a nasal script. Either way, this approach should work fine without any modification to the viewer or viewmgr classes. Adding this (as I described here) as extended functionality to the viewer or viewmgr class is probably not a good design option. Best, Jim
Thanks for the input. For now I have just added a hack to recalcLookAt which checks a property for the current selected multiplayer and exchanges _target_location with a new location based on the multiplayer. If there is no multiplayer _target_location is reset to yourself. I can then use nasal to set the callsign of the multiplayer to watch, and initially also replace position properties in the different views such as the helicopter view to be relative to the multiplayer instead of the player. This was quite easy to do, even for someone who hasn't seen the code before, that it would probably be more elegant to Inc in to the already existing review management system by adding views as you describe. I will just have to study the code a bit more :)
Can you think of any easy way of making the view is defined in preferences.xlm relative to the currently watched aircraft? As I said previously my idea thus far is to modify properties in the current view when the aircraft is changed. This works for the helicopter view and chase view, but it is not necessary for the tower view for instance. Also, the cockpit view seems a bit challenging since there are no position references in its definition :)
-- Frank Olaf Sem-Jacobsen ------------------------------------------------------- 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
