> From: simon > > Jim Wilson wrote: > > 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 > > > > I don't think adding more views is the way to go long term. Would you > add multiple views (cockpit/helicopter/chase) for each multiplayer > aircraft? For each AI aircraft? For each carrier? For each X model? > That's a lot of views to scroll through to get the one you want, not to > mention the redundancy overhead.
A couple of emails back I wasn't sure exactly what was wanted so I suggested two different approachs. This was one of them. > To me, a view is really just a set of position and orientation sources > and targets, position and orientation offsets, fov and a few other > configuration settings. My goal is to be able to switch from-model > type, index, and offset, at-model type and index for any given view. > Not only would it be nice to be able to switch the model you're viewing > from (multiplayer,tower,carrier), it would be nice to switch the model > you are looking at, if any. Basically, a more open viewing system that > would allow fly-by views using nasal (my original goal), bomb - uh, I > mean drop tank - view all the way to the ground, switching models by > type, and anything else you can dream up in nasal. > Right. It is pretty open already. What you say in the first sentence of this paragraph is true. That's pretty much all a view is. For this reason I was suggesting (in my second option in the earlier e-mail) that you could create 2 or 3 (or how many you wanted) views that are expressly designed for MP Aircraft. Then the nasal script (or C++ code) could simply copy the position/orientation data from the "current" MP aircraft specific property tree location, to the property tree location that is referenced in the xml configuration for these special MP views. Make them special views and you won't have to worry about confusing the use of view configurations with too many levels of indirection...or dealing with some other special view configuration in the future. Remember your nasal script doesn't have to force the user to scroll through all 5 (or 6?) of the current FlightGear views plus the MP views. With the script you can scroll through whatever views you want to in wha! tever order you want. > > I've actually worked on this a bit: > > I've moved all the redundant property copying from viewmgr into tied > properties in viewer. I've created properties for from-model-type > (default,carrier,multiplayer,tower,etc..), from-model-idx, > from-model-offset (pilot,copilot,bomb door,etc..), at-model-type, > at-model-idx. The position/ and orientation/ properties have become an > interface of sorts to each model. Instead of using SGLocation directly, > I copy directly from a $prefix/position/* and $prefix/orientation/* > into the viewer's SGLocation. The $prefix is generated by type and > index and types and paths are defined in preferences.xml. I'm having > issues switching between look from/look at dynamically. That part may > have to wait. > > I hadn't planned on this being brought up again pre 1.0, so it's not > even close to being ready to look at. I'm not even sure if it's desired > or the right way to do it. However, while I can see having a view > defined for everything could work with a good bit of hackery, it just > doesn't seem like the right way to do this. > See above. I forget now...isn't there some savings to sharing an instance of SGLocation between classes? Is the shifting of functionality as you describe here making the view more or less flexible and how? It isn't clear yet. 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
