First of all, sorry for my -- once again -- harsh posting. I was just
a bit overwhelmed by an "AARGH" feeling. ;-)
* On Dec 27, 2007 12:42 PM, Syd&Sandy <[EMAIL PROTECTED]> wrote:
> The reason behind this was a new monitor , now I have to set FOV to 70 for
> a decent view...
And that's exactly one of the problems with the solution. People who
want a different default FOV due to their monitor's geometry will probably
*not* want that to depend on the aircraft. This should be solved on the
fgfs 'system level'. And the discussion about this didn't seem to be
finished to me, so I was a bit unpleasantly surprised to see that committed
to several aircraft.
Another problem was, that you also saved the FOV of views that do really
not belong to the aircraft, such as the tower views. I'd only consider
cockpit view and aircraft specific views (>=100) owned by the aircraft.
And yet another problem was, that the code was wrong. It doesn't save the
view index, but the index of the view in the getChildren() vector:
! var view = props.globals.getNode("/sim").getChildren("view");
! for(var i=0; i<size(view); i+=1){
! append(view_list,"sim/view["~i~"]/config/default-field-of-view-deg");
! }
You should have written something like:
foreach (var v; view.views) # it's safe to grab the vector from view.nas
aircraft.data.add(v.getNode("config/default-field-of-view-deg"));
or at least use v.getIndex() rather than the counter i. The difference is
that i will be 7 for <view n="100">. Or 8 after adding a new system view,
or 9 etc. v.getIndex(), on the other hand, should always be 100, unless
you change that in your *-set.xml file, of course.
> Melchior can speak better to the
> purpose of the aircraft specific save file since this was his invention and
> it's somewhat complicated (but also with a high amount of functionality.)
>
> My understanding was that this might have been for things like did you leave
> the doors open on your bo105, or what livry did you select most recently for
> a given aircraft.
Yes. Whatever the "aircraft" wants to save, except: things that don't belong
to it (such as 'menubar visibility'), or things that should always start with
a sane default (tank filling level, trimming). Of course, optionally saving
whole states would be nice (like ac_state.nas does), with parking brake state,
switches, trimming and everything, but we have yet to make that generic and
selectable.
> I think even Melchior will (might?) :-) agree that there is always some gray
> area and overlap when organizing features and laying out possible
> functionality.
Yes sure.
> changed out from under me ... well if I'm Melchior anyway, then I raise holy
> hell on the mailing lists. :-)
Yesss! :-}
> I will agree that there is a default FOV issue here, but don't we have a
> non-aircraft specific place to save persistant options?
Exactly. autosave.xml
> If a user wants to change the default FOV for their system, i have no problem
> with making that easy to do, and no problem with saving that out somewhere,
> but just not in aircraft specific save files please.
Agreed. I don't know how well Maik's suggestion works (calculating FOV from
height/width), but some widget in the "View Options" dialog and a "userarchive"
flag for the property would be fine with me. But I think this should only be
done for the cockpit view. If a slider isn't precise enought, then make
an input-field *and* [+] and [-] button or something. We can still improve
that later if necessary.
m.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
