Board index FlightGear Development

Possible bug: New flight recorder / carriers

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

Possible bug: New flight recorder / carriers

Postby sgofferj » Fri Jan 27, 2012 1:38 pm

Hi,

I just discovered a possible bug in the new flight recorder. I was flying an EC135 out of KSFO to the Nimitz and landed. After landing I reviewed the approach and the landing in the flight recorder. When I exited the flight recorder, the Nimitz was a couple of 100m away and my EC135 was hovering in the air with engines off - just to fall into the water immediately...
Maybe the flight recorder should not freeze the aircraft while it is replaying ^^.
The question is - is this a bug in the flight recorder or a faulty config of the EC135?
FG 3.1 GIT / Opensuse 12.3 / Phenom II X4 / GForce GTX560
Stefan's little Flightgear corner | The Finnish Weather Center | Wolves in Finland

Working on: EFTP
COM: IAX2:home.gofferje.net/stefan (MO-FR 0700-2000 UTC, SA+SU 0900-2000 UTC)
sgofferj
 
Posts: 789
Joined: Mon Dec 05, 2011 4:13 pm
Location: EFTP
Callsign: OH-SW
Version: 3.1 GIT
OS: Opensuse

Re: Possible bug: New flight recorder / carriers

Postby someguy » Fri Jan 27, 2012 4:14 pm

I think it's just the way the AI carrier interacts with the recorder. While you're watching the replay, the carrier is steaming forward; the recorder returns you to where you were when the replay started...but the carrier is gone now. It's probably a unique case that will never be addressed by developers. If it annoys you, edit AI/nimitz_demo.xml so the carrier's speed is zero. Lots of us do that anyway, so we can "share" our AI carriers with other pilots and make fun of each others' landings. :)
User avatar
someguy
 
Posts: 1084
Joined: Tue Nov 25, 2008 5:54 am
Version: 3.0
OS: OS X 10.9.2

Re: Possible bug: New flight recorder / carriers

Postby ThorstenB » Fri Jan 27, 2012 4:29 pm

Neither. It's a feature we currently don't have. ;-)

You could either change the AI carrier implementation to freeze carriers when replay mode is active. This should be a pretty simple change and probably the best short term solution.

Or you could change the flight recorder configuration to also record and replay the carrier position. But this may require a larger change to the code moving the AI carrier and also require a change of the flight recorder configuration. Also, it's not feasible to record the position of every single object in the scenery, so you'd have to restrict it to a certain number.

And since someone else has also asked a similar question concerning MP traffic and clouds: those are also not recorded by the flight recorder. So, it's the same for clouds and fog, which isn't going to be in the same position during or after replay. It'd just be too much for the system to record absolutely everything. ;-)
User avatar
ThorstenB
 
Posts: 160
Joined: Fri Nov 19, 2010 9:49 am
Location: Germany
Callsign: D-TB7
Version: GIT
OS: openSUSE

Re: Possible bug: New flight recorder / carriers

Postby Hooray » Fri Jan 27, 2012 6:01 pm

ThorstenB wrote on Fri Jan 27, 2012 4:29 pm:And since someone else has also asked a similar question concerning MP traffic and clouds: those are also not recorded by the flight recorder. So, it's the same for clouds and fog, which isn't going to be in the same position during or after replay. It'd just be too much for the system to record absolutely everything. ;-)


Arguably, this is something that the corresponding sub systems (i.e. AI/weather) should handle themselves internally, while I cannot speak for the AI traffic system, the local weather system should theoretically be capable of pulling that off with some not so significant changes.

Thorsten may want to comment on the details. But basically, we'd need some "replay" signal, register a listener and then internally buffer the positions of clouds for a configurable duration, so that local weather state could also be replayed.

A couple of weeks ago, I looked into refactoring local weather. Part of that involved changing more stuff to native Nasal data structures. So this would be pretty useful for collecting/replaying state. Unfortunately, I managed to introduce some pretty subtle bugs that I wasn't able to fully debug yet...
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
Nasal | Projects | Core development |
Programming resources
Hooray
 
Posts: 5600
Joined: Tue Mar 25, 2008 8:40 am

Re: Possible bug: New flight recorder / carriers

Postby someguy » Sat Jan 28, 2012 4:13 am

Maybe I'm missing something, but I'm having a hard time seeing Replay as important enough to risk breaking other stuff that works fine otherwise. Just zero your carrier speed and enjoy.

Or...use a JSBsim plane that won't crash when it gets a little wet. :)
User avatar
someguy
 
Posts: 1084
Joined: Tue Nov 25, 2008 5:54 am
Version: 3.0
OS: OS X 10.9.2

Re: Possible bug: New flight recorder / carriers

Postby Thorsten » Sat Jan 28, 2012 9:41 am

Arguably, this is something that the corresponding sub systems (i.e. AI/weather) should handle themselves internally, while I cannot speak for the AI traffic system, the local weather system should theoretically be capable of pulling that off with some not so significant changes.


We do have an internal Nasal record of where every cloud currently is. Since the wind doesn't change while you execute replay, you could save the value of the timer at the moment you start the replay, when you end it use that to compute to where the cloud has drifted since and correct the position be executing a couple of thousand move-cloud() calls.

I have a hard time imagining why this should be important enough to spend even 20 minutes on coding it though.

Also, it seems to be down to details. In single player mode, you can freeze the time of the whole system for the duration of your replay. In multiplayer you can't, it has to run on for others. So it's not even clear to me how the system should reasonably behave.
Thorsten
 
Posts: 2879
Joined: Mon Nov 02, 2009 8:33 am

Re: Possible bug: New flight recorder / carriers

Postby Hooray » Sat Jan 28, 2012 10:30 am

Thorsten wrote on Sat Jan 28, 2012 9:41 am:I have a hard time imagining why this should be important enough to spend even 20 minutes on coding it though.

I see, I think the problem is that replay cannot work for certain sub systems if these systems don't have a concept of replaying a recorded flight. So, basically subsystems not honoring other subsystems, make it impossible for them to work fully/properly. It would be impossible for replay to handle the needs of all other subsystems. So it's all about clearly defining responsibilities. And I actually agree here: At the moment, this isn't critical or crucial at all: The lack of replay support is not a major showstopper currently. However, at some point this may introduce additional breakage because other features are getting built on top of systems that are not fully supported.

For local weather it might actually be a worthwhile feature for different reasons: more and more improving the architecture. There are a number of related features that would be directly related to being able to interrupt and resume the system gracefully.

For example: At the moment, it isn't possible to save and load flights in FlightGear, but ThorstenB mentioned already that he's planning to support this for recorded flights eventually. Now imagine you were demonstrating FlightGear to new users or using FlightGear in an instruction-related scenario. You'd probably want to be able to also record and replay environmental aspects of the simulation, such as weather/clouds? But also AI traffic?

But there are other features that are not yet supported in certain use cases, i.e. connecting multiple FG instances in a master/slave fashion, AI, multiplayer. Basically, this is all about synchronizing state across several clients/instances. Some parts of FG try to work around these issues by using a corresponding RNG with a shared seed.

But at some point, this will inevitably require a capability to serialize some active subsystem specific state in order to de-serialize it somewhere else. Regardless of it being in a multiplayer setup or master/slave setup, or just the plain capability to save and continue a flight at a later time.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
Nasal | Projects | Core development |
Programming resources
Hooray
 
Posts: 5600
Joined: Tue Mar 25, 2008 8:40 am


Return to Development

Who is online

Users browsing this forum: No registered users and 1 guest