Re: [Flightgear-devel] Reset Problem ?
Norman Vine <[EMAIL PROTECTED]> said: > Anyone else seeing a problem when resetting > while in 'chase view' > > Norman > What I'm seeing is the xyz (eye) offsets are getting reset to whatever the view[0] (generally pilot view) has in it's config. I'll sort it out today. Anyone opposed to reset forcing back to view[0] if that turns out to be the easiest route? Curt are we marking a release today? If so when? (ie when do i need to get this fix in?). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Reset Problem ?
Jim Wilson writes: > >Norman Vine <[EMAIL PROTECTED]> said: > >> Anyone else seeing a problem when resetting >> while in 'chase view' >> >> Norman >> > >What I'm seeing is the xyz (eye) offsets are getting reset to whatever >the view[0] (generally pilot view) has in it's config. I'll sort it out >today. Anyone opposed to reset forcing back to view[0] if >that turns out to be the easiest route? That sounds like a good 'temporary' solution at least but IMHO we should be able to reset and or teleport from any state and keep as much of that state as possible The solution probably lies in the question why does 'goto airport' work for chase view but not 'reset' ? FWIW I have found that the 'reset' and 'goto airport' routines 'good' tests for making sure you still have control of the program flow :-) FYI I also seem to be getting a different 'scenery normal' for view[3] then view[ 0, 1 or 2 ] ??? I haven't really investigated as to why yet Cheers NOrman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Reset Problem ?
Norman Vine <[EMAIL PROTECTED]> said: > FWIW > I have found that the 'reset' and 'goto airport' routines 'good' > tests for making sure you still have control of the program > flow :-) > That's a good guess...like using "restoreInitialState()" that just copies all the properties as they were saved on intialization? That's the problem. Is there any way to control what gets restored, short of making the property read only? Or should I insert a call (in the reInit() routine) to the view manager to clean up the mess? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Reset Problem ?
Jim Wilson writes: > >Norman Vine <[EMAIL PROTECTED]> said: > >> FWIW >> I have found that the 'reset' and 'goto airport' routines 'good' >> tests for making sure you still have control of the program >> flow :-) >> > >That's a good guess...like using "restoreInitialState()" that just copies >all the properties as they were saved on intialization? >That's the problem. >Is there any way to control what gets restored, short of >making the property >read only? Or should I insert a call (in the reInit() >routine) to the view manager to clean up the mess? My guess is that you want to make a 'snapshot' of the property tree at the begining of reinit() and restore 'those things' that are 'pertinent' from the 'snapshot properties' just before returning from reinit(). Just what 'those things' are will probably have to be discovered by trial and error 'again' but this is obviously one. FWIW IMHO this is a result of the general switch to the 'properties' and I will leave it to the 'experts' to determine what they want the behaviour to be Note that in the case of 'reset' a simple check for viewer mode could be made in GUI / reset.cxx before calling reinit() and the viewer_mode can be changed to mode[0] and then be reset after reinit() returns. Whether we do this or leave it in mode[0] really doen't matter, but coming up with a 'white' screen after performing a reset from chase mode is unacceptable so something should be done before we make a release ! Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Reset Problem ?
Norman Vine <[EMAIL PROTECTED]> said: > Whether we do this or leave it in mode[0] really doen't matter, but > coming up with a 'white' screen after performing a reset from chase > mode is unacceptable so something should be done before we make > a release ! > Actually the white screen was the wall of the cockpit, kind of like passing out, falling on the floor (if there was room) and waking up looking at the wall. It's been fixed in CVS. Ended up putting in a call to the viewmgr so that it fixes the current view offsets made wrong by the restore. Note that it stays in whatever view mode you were in. While looking at this I wondered why there are two different routines, one for reseting and one for teleporting. Seems as though they should do the same thing. And at least making it one routine would reduce the battle against the bugs down to one routine. I can't tell you exactly how to reproduce this, but if you do enough teleports and resets the program will eventually crash...and for some reason no core file. Also if you try to teleport while the plane is moving (under JSBsim) chances are you won't make it. Finally try teleporting after you crash the plane. It will try. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Reset Problem ?
Jim Wilson writes: > >Norman Vine <[EMAIL PROTECTED]> said: > >> Whether we do this or leave it in mode[0] really doen't matter, but >> coming up with a 'white' screen after performing a reset from chase >> mode is unacceptable so something should be done before we make >> a release ! >> > >Actually the white screen was the wall of the cockpit, kind of like passing >out, falling on the floor (if there was room) and waking up looking at the >wall. He He > It's been fixed in CVS. Great ! >While looking at this I wondered why there are two different routines, one for >reseting and one for teleporting. Seems as though they should do the same >thing. And at least making it one routine would reduce the battle against the >bugs down to one routine. My guess is that if 'teleporting' changed the 'airport-id' in the 'initial-conditions' this would work. Otherwise you need two routines or at least a wrapper routine. >I can't tell you exactly how to reproduce this, but >if you do enough teleports and resets the program will eventually crash...and >for some reason no core file. I have seen this too.. But I am not convinced yet that it is the teleporting that causes the crash. ie way back when I introduced teleporting it appeared to be 'bullet proof' note this was before even JSBSim was an FDM and the 'properties'. A lot has changed since then and I am not convinced that all of the additions since then know how to 'reinitialize' themselves or that we know what needs to be reinitialized. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
