Old 744 Forum

Archived posts

Digital Flight Data Recorder for PSX (DFDR) 0.9.0 Alpha released

Page: 1

Author Post
Member
Registered: Jan 2013
Posts: 318
Location: YSSY
Hi all,

here's another addon I've been playing around with. It's still a bit rough around the edges, but you should be used to that by now.

It's a flight data recorder that allows recording of your flights (with some limitations, I'm currently having trouble still correctly saving the complete initial state when commencing the recording - hence best to start out with a situ you either create or already have, then start recording). But take a look at the website for more info and the download.

http://www.inside.net/ss/

This could be useful if you want to send sim behaviour examples to your colleagues (or Hardy...).

Cheers

- Balt
« Last edit by Balt on Fri, 30 Jan 2015 03:58:15 +0000. »
Moderator
Registered: May 2009
Posts: 5140
Wow, you are very productive! :-)

Can you make it Java 1.6 compatible? I can't launch it with 1.6 and 1.7. Same version problem as recently.


Thank you!

|-|ardy
Member
Registered: Jan 2013
Posts: 318
Location: YSSY
This one is compiled for 1.7 (like all my other addons). 1.6 is a bit on the outdated side, not sure I have even seen that as a download option from Oracle? Why are you staying on 1.6 when 1.8 is available as a free download? Issues with 3rd party libs?

I'd appreciate some more input from you on how to complete save the state of the sim. sending "bang" should give me a list of all the state variables, but that doesn't always work. Interestingly, sometimes it does though... So I'm not sure what the purpose of translating the Qi/Qs/Qh codes to their lexicon alternative names would do, other than just feed the same variables known by a different name back into the sim?

Cheers

- Balt
Member
Registered: Jan 2013
Posts: 318
Location: YSSY
My build environment was stuffed up and used 1.8 again... I've recompiled for 1.7. So can you please re-download and let me know if it works with your 1.7 now?

Thanks

- Balt
Moderator
Registered: May 2009
Posts: 5140
It works now with 1.6 and 1.7.

Brilliant!

You don't need to "bang". You get all vars at net connection, or when a situ is loaded.

Do you monitor the commands ...

load1
load2
load3

... from the server?

One thing, however, should be considered re position and attitude initialization when starting a playback. This has something to with the Qs PiBaHeAlTas and StartPiBaHeAlVsTasYw which bypasses the motion damping at the start. PiBaHeAlTas injections are dampened. If you run a China playback and then start a France playback, it takes a while until the damper has moved the coords across the continent.

Are you using StartPiBaHeAlVsTasYw?


Cheers,

|-|ardy
Member
Registered: Jan 2013
Posts: 318
Location: YSSY
Ah.. no. I'm blissfuly unaware as to such internals... thanks for the info. So this could be addressed by simply sending the StartPiBa... with the current value of PiBa... on commencement of the playback?

The server connection is persistent, i.e. lives across recordings and playbacks. So that default dump is not happening at every start of the recording. I thought "bang" did the same thing as the inital connection (but as I see from the content of the data files it doesn't).

I'm monitoring everything that is sent out, if load messages are coming in, they will be played back. Not sure what that means... good or bad?

Cheers

- Balt
Moderator
Registered: May 2009
Posts: 5140
Yes, StartPiBaHeAlVsTasYw should be sent whenever a situation is to be sent (i.e. at the start of a playback).

This var is one of those that run in START mode (not in ECON or DELTA etc.). START mode vars are only used at situ start. Thereafter they are not updated because the process of their values is deterministic.

START mode vars are mainly used at places where damping and spooling is used, i.e. where the stored values are target values. The actual values are not sent (in order to relieve the network). Only the targets are sent. E.g. the nose cargo door position, and many engine parameters are initialized by START mode vars.

Only the server can store a situ. PSX clients cannot store situs because they don't know the START mode vars. Similarly, add-on clients cannot know them either. They need to calculate them on their own when saving a situ during runtime outside of PSX.

You are going new paths with your add-on. This requires more documentation on my side. Unfortunately, I'm currently very busy with version 10.0.2, so we need to postpone this discussion for a few weeks.


Cheers,

|-|ardy


I'll check if "bang" makes the server to update START mode vars before it bangs off all vars. It should do this. If not, I'll try to fix it in 10.0.2.
« Last edit by Hardy Heinlin on Mon, 26 Jan 2015 13:20:26 +0000. »
Member
Registered: Jan 2013
Posts: 318
Location: YSSY
Hi Hardy,

no stress! I've just had a bit of a read of the network documentation, many of my initial assumptions/questions are answered there.

If there was a way for an addon to send a "save situ" command (and, "load situ") that would of course facilitate all of this drastically. e.g. at the start of a recording, I'd send a "save situ /whatever/path/2015-01-27_223344.dfdrdata.situ" and then store the delta stream into the corresponding dfdrdata file.

For replay, just issue the command "load situ /whatever/path/2015-01-27_223344.dfdrdata.situ" and start streaming the time synchronised playback. That part, turns out btw, is rather tricky. It works well as long as the playback runs faster than the simulation originally did because I can adjust the runtime with a realtime counter, but I can't make it catch up in case it goes slower. There are some inherent limitations to this.

But all in all I think this is going to be a very powerful addition for demo and analysis purposes!

Cheers

- Balt
Moderator
Registered: May 2009
Posts: 2449
Location: KTMB
Lexicon and DFDR is interesting.

The Lexicon is meant to provide a layer of abstraction between program code (readable references) and network code (brief Q codes). DO NOT code against Q codes as your program will be unreadable and fragile. Instead, at least use an assignment table so you can use constants or variables to hold the Q codes. This table may be fixed (download lexicon once during development) or dynamic (load once per network session). Technically the difference is small so it is up to you.

For DFDR addons, playing back a file from PSX rev 1 to PSX rev 2 is a challenge. Only if you store the received data using Lexicon codes instead of Q codes you have a really good chance to play it back in the future. But Hardy strives to not change Qs, only add, so the difference is not going to be fundamental.

Still, the Lexicon is valuable. Do not just bypass it without due consideration.


Hoppie
Moderator
Registered: May 2009
Posts: 5140
Hi Balt,

I think playback related situ saving stuff should be completely performed inside the recorder add-on. Perhaps it would even be nice to save and embed a situ in the recorder file every 20 seconds or so. This way you can safely replay a short part instead of restarting the playback from the very beginning.

Without the START mode vars, a playback works (partially) like a macro. And a macro always needs a starting point.


Cheers,

|-|ardy


Hoppie and I, as usual, disagree regarding the lexicon stuff :-) I promise the Q codes will never change. Originally, the lexicon was used to assign changed Q codes. But they won't change anymore. I promise. Now the lexicon is only a means to show the Q codes in English (shows "PiBaHeAlVs" instead of "Qs999").

For the recorder file I would use Q codes instead of lexicon names because Q codes are much shorter, hence more performance friendly. For an analysis screen one can translate them to lexicon names anytime.
« Last edit by Hardy Heinlin on Mon, 26 Jan 2015 14:17:33 +0000. »
Member
Registered: Jan 2013
Posts: 318
Location: YSSY
...that's a really good idea (saving a situ every x seconds). That way the user can fastforward/rewind ad libidum.

I'll think about this tomorrow...

Cheers

- Balt
Moderator
Registered: May 2009
Posts: 5140
Hardy Heinlin wrote
I'll check if "bang" makes the server to update START mode vars before it bangs off all vars. It should do this.

Just checked my code. It does. (Function was added in March 2011.)

You get fresh START mode vars when you send "bang".
Member
Registered: Nov 2011
Posts: 77
Sorry, is this project still under development? When I try to run it it says it's expired

Tnx

Andrea
Member
Registered: Jan 2013
Posts: 318
Location: YSSY
I've updated the expiration date to end of July. I'm not sure this project is going anywhere, I think Hardy has something in the works that will be much better than this (Hardy?).

I'm busy in my very scarce free time working on the realistic wind shear project... watch this space for updates in the coming weeks!

Cheers

- Balt
Moderator
Registered: May 2009
Posts: 5140
Nope, I have no video recorder in the works. It's way more complicated than one would think when considering the easy network access. A fully working video requires much more than just recording a handful of variables ... I knew why I discarded the idea of implementing a video recorder some years ago :-)


Cheers,

|-|ardy

Page: 1

Old 744 Forum is powered by UseBB 1 Forum Software