The future of LEAVU, a more general tool?

It has been quite a while since I last worked on anything related to Fc. Now I have a

couple of weeks of vacation and I've got some ideas.

Initially I thought I would implement these in Leavu2, however eventually

I realized that Leavu2 was written when I was very green in terms of Java

programming. Also even though leavu theoretically could be used with any

sim, that was not its initial design idea, so it would be very messy.

So I've decided that if I'm going to make any new tools like leavu, it would

have to be an entirely new tool written properly from the ground up, with much

better ability for extensions, custom new instruments by users and an easier

architecture to code. Also a new and cleaner data export would be required.

So I'd like to present some of the things I've worked on for the last couple of days,

so far what I call GEAR. General External Avionics Renderer, the name should be

changed to something less silly. Come on Leavu? Gear? TIACAFAP (This Is A Cool

Abbreviation For A Program).

GEAR is NOT an mfd. GEAR is an arbitrary instrument loader for any sim.

Here below is a picture from early work on the instrument I'm in the process of

implementing right now. The idea is that more users/developers will come with ideas

and hopefully implement new instruments themselves, so that we could create a

nice database.

Here's how it works:

GEAR has a few parts, some are optional. Some are included, many are not, and that is intentional.

The minimum required parts are:

* GEAR: the instrument loader (sim independent)

* DATA EXPORT: a sim specific data export module for your sim (I am making one for fc2, virtually done)

* DATA EXPORT INTERFACE: a data interface inside the GEAR instrument loader which receives and translates

the sim specific details from the data export to formats that the GEAR instrument loader can use.

(I am making one for fc2)

The optional parts so far are:

* GEAR: Datalink server (sim and data format independent through Java Serialization interface).

This server can handle both sim specific messages or just general GEAR data.

Unlike leavu this is not a separate application but is actually launched from inside the GEAR instrument loader itself.

* DATALINK INTERFACE/CLIENT: a data interface between the GEAR loader and the datalink server

(I have so far made one implementation capable of sending fc2 data)

* THE INSTRUMENTS!: Pick an (or a couple of) existing one, make your own or dowload someone else's

From the users point of view all the above are just the same program

(except the first which is made into something loaded by the sim)

Usage:

A user starts the instrument loader and loads an instrument profile (which can be made to

happen automatically on startup, think like touch buddy), or just adds instruments from a

menu. When he started it he also specified which simulator he would like to get data from

and what data interpretation layer he wishes to use.

Some details on what GEAR is intended to be:

- Open Source (written in Java with some custom native JNI additions)

- An high performance (low CPU/GPU load) opengl renderer for 2d instruments (or ability to add whatever u like).

Instruments run at whatever rate you want them, for example 100 fps. JOGL is used.

- A standardized abstracted interface to make it work with any sim, (so you can

implement your own data export from other sims, regardless of coordinate systems etc).

- A standardized abstracted interface to potential datalinks. (Currently I've only made an implementation for Fc2).

- Compared to Leavu? Much cleaner design, code, rendering and data propagation/interfacing. Much easier to make own additions. Significantly better data export from lockon. Much easier installation. (Significantly faster, can run about 50 simultaneous display on 1 core)

I know there was a lot of debate on leavu this and leavu that. This time I can frankly say

I won't hold back on posibilities. I will make the instruments that I myself implement as

useful as they can be on own sensor data.

Note on the miserable failures of the LEAVU 2 renderer ;)

- The old Leavu rendering setup is completely scrapped. It had an ugly abstraction layer between instrument and renderer, which made absolutely no sense. A new much lighter

interface like setup is now made. The only part really remaining in the graphics department

is the coordinate system :).

Programming API example:

Here is a sample on how you could implement your own rendering/instruments.

You write a Java Instrument as an AWT window/component or similar, you add

an OpenGL Canvas (rendering surface) to it.

Then you implement a specific OpenGL callback interface, which has only one

function :glPaint, example below.

public final class Mfd20 extends Instrument implements GlDisplayCallback {

   protected DataInterface dataInterface;

   @Override
   public final void glPaint(final GLAutoDrawable gLDrawable, final GL gl, final GLU glu, final Object cbd) {

       gl.glColor4f(1, 1, 1, 1);

       gl.glBegin(GL.GL_LINES);
       gl.glVertex2d(0, 0);
       gl.glVertex2d(1, 1);
       gl.glEnd();

       if (dataInterface instanceof WaypointsInterface)
          InterfacedWaypoint[] ifwp = ((WaypointsInterface)dataInterface).getWaypoints();

   }

}

The code above produces the following image:

Yes it's an mfd but only because it's the onl instrument I got at the moment :P. You could make it look like whatever you want.

About overlaying the game graphics themselves

I don't think that would be something I could do within a reasonable amount of time. It would require some form of dll injection (replacing the direct3d dlls with your own custom built ones and tricking fc2 to run it - that way you can inject custom draw/paint instructions or export data/textures) like what AISTv is doing. Since I'm working in Java that would be virtually impossible, unless I (as I see my options) made some kind of client-server (for example using windows shared memory or just plain old network sockets) setup where the GEAR part produces a texture which the injected dll running can receive and overlay.

Well although I probably COULD figure out the above, I would still need to find out where to place the texture, how do I find somewhere in the cockpit to place it? :P. At this point I have no experience of direct3d dll injections and my attempts att contacting the aistv author have not been successful. Also I will have a lot of work just to get the intended GEAR features finished in the near future.

However:

If someone supplied the source code or made such a dll for me! (or wanted to co-author the project or similar)

That would be a whole different thing, then I would definitely see if I couldnt implement it.

Performance and CPU hit

With gear comes a lot more efficient code compared to the old Leavu. Here is an example of how much CPU % gear @ 60 fps requires from my i7 @ 3.36 GHz.

Ok for everyone that wants to inspect and/or contribute to the source, "Public" SVN account is up! (read-only)

It includes everything you need, from fc2 exports to native jogl libs and java code.

I recommend you use Netbeans IDE for both checking it out and trying it.

1. Install 32bit Java JDK with Neatbeans

2. Open Netbeans and checkout the SVN repository from:

rep: https://www.gigurra.se/svn/GEAR/GEAR

user: public

password (blank):

If you could make it display atop a full-screen application for those of us without two monitors, then you'd really be on to something!

If you could make it display atop a full-screen application for those of us without two monitors, then you'd really be on to something!

I don't think that would be something I could do within a reasonable amount of time. It would require some form of dll injection (replacing the direct3d dlls with your own custom built ones and tricking fc2 to run it - that way you can inject custom draw/paint instructions or export data/textures) like what AISTv is doing. Since I'm working in Java that would be virtually impossible, unless I (as I see my options) made some kind of client-server (for example using windows shared memory or just plain old network sockets) setup where the GEAR part produces a texture which the injected dll running can receive and overlay.

Well although I probably COULD figure out the above, I would still need to find out where to place the texture, how do I find somewhere in the cockpit to place it? :P. At this point I have no experience of direct3d dll injections and my attempts att contacting the aistv author have not been successful. Also I will have a lot of work just to get the intended GEAR features finished in the near future.

However:

If someone supplied the source code or made such a dll for me!

That would be a whole different thing, then I would definitely see if I couldnt implement it.

1. Would we be able to use this online without fear of anybody making some sort of uber app that would have info that shouldn't be there?

2. Are the buttons on that MFD clickable/useable?

Most of the stuff you said is foreign to me, so it may take me some time to understand what your saying.

1. Would we be able to use this online without fear of anybody making some sort of uber app that would have info that shouldn't be there?

I'm going to interpret that question in two ways and answer both.

1. "Would we be able to use the gear data export scripts online with fear without fear of anybody making some sort of uber app that would have info that shouldn't be there?"

- Depends. The data export scripts export own sensor data. Allowing such a data export script means removing export.lua file from integrity check (or having a standardized file). Doing either of these does NOT allow export of global data (tacview style), but there is at least one bug in fc2 itself that causes more data to be available for export than the in-game instruments show. More precisely, there is a bug: own sensor radar data available does not mask ecm contacts. This is a bug in lockon, not gear. Even though my own data export scripts don't deliver this data to Gear, someone could potentially do that by writing their own data export script.

Once the own sensor data is out of the game, developers can do whatever they like with it. It's a law of physics or whatever you want to call it, doesn't have anything to do with gear :). Developers could make whatever app they like from it.

Now we are ready to answer #2

2. "Would we be able to use the gear in its entirety online with fear without fear of anybody making some sort of uber app that would have info that shouldn't be there?"

Depends on what you think shouldn't be out there (read full gear description in 1st post before following below). The gear instrument loader could potentially load any type of 2d or 3d instrument showing any infromation in any format based on data received from either:

# the fc2 data export scripts/interface of own sensor data

# the gear data link server, players connecting and sharing own sensor data

if either of these two data sources can produce knowledge that you find "shouldn't" be out there, then you have your answer, cause instruments and data representation in Gear can be made to look like whatever you want them to, certainly a lot more informative than the existing ingame instruments.

For example: Would it be possible to create a GCI application or AWACS application connecting to the data link server, and sending information to players gear instruments through the data link, even controlling players' games with stuff like radar command input? Yes in theory. Has nothing to do with gear really.

As soon as you allow export of own sensor data - That is all that is needed.

- Gear is an application of that.

2. Are the buttons on that MFD clickable/useable?

 

Most of the stuff you said is foreign to me, so it may take me some time to understand what your saying.

Yes gear is a bad name, cause instruments can be made fully interactive (like leavu, even more so), and can also send commands back to lockon should you wish to implemetned that (like modify radar scan angles, cursor positions etc).

Further more I made my mfd instrument a little bit more futuristic by making the screen itself work like a touch screen. So my mfd instrument has three input methods: click with mouse/touch screen on bezel buttons, click with mouse/touch screen on mfd screen, use keybindings.

I implemented an mfd menu system that is 1:1 with falcon 4, even though the specific pages implementations are differnt.

Code example below on how I've done it for my HSD page:

   @Override
   protected final void inputOsbCommand(final OsbCommand osbCommand) {
       switch (osbCommand.osb) {
           case (depOsb):
               DEP = !DEP;
               break;
           case (dcplOsb):
               DCPL = !DCPL;
               break;
           case (expOsb):
               expIndex = expIndex + 1 < expViews.length ? expIndex + 1 : 0;
               break;
           case (netOsb):
               NET = !NET;
               break;
           case (hsiOsb):
               HSI = !HSI;
               break;
           case (scaleUpOsb):
               displayScaleIndex = (higherDisplayScaleAvailable() && DCPL) ? displayScaleIndex + 1 : displayScaleIndex;
               break;
           case (scaleDownOsb):
               displayScaleIndex = (LowerDisplayScaleAvailable() && DCPL) ? displayScaleIndex - 1 : displayScaleIndex;
               break;
       }
   }

Thx for the answering my questions.

First thing im going to do after the fc2 interface is to make an x-plane interface, maybe also a hud in there since it's so easy to overlay x-plane graphics :)

sounds really great Yoda,

good to hear work on the FC2 part is nearing completion.

Standing by for initial release.

Quick question. I admit maybe i was lazy to read carefully, but does that work on one screen as overlay or only on other display devices?

Only separate screens, because I do not know how to make it into an overlay.

If you have example source code overlays for lofc2 then I could probably integrate it,

but researching and learning that myself would take too much time away rom my

primary goals with gear. Besides we would probably also want to find out a way to

place it overlayed on top of the cockpit mfd, and that would is even further away from

what I know how to do :).

sounds really great Yoda,

good to hear work on the FC2 part is nearing completion.

Standing by for initial release.

The gear data data propagation design is nearing completion, though I expect the fc

parts will never be "done", altough specific instruments will. Important is to separate

"This instrument is done" (will probably happen at some point),

"Gear is done" (what does this even mean?)

For example someone could make some kind of VVI instruments or AOA instrument,

those might get *done*. I myself might say "ok now my mfd is done", though someone

could easily enhance it by adding further pages to it. Neither of these two though, would

qualify as "now GEAR is done".

I am glad you are back on FC2-LEAVU programming.

Wish Ed would fix people firing missiles when they are missing the radar/radome. I thought the Russian jets can't fire them without a lock also.

Off-topic: Russian aircraft can fire missile with out locking and active missile can pick up target by himself if it's fired in close proximity to the target. What I would like to see is part's or full LRM mode back.

Gotta love the active missile spammers when they are going down in flames.

Just to give a quick progress update. I'm out here in the middle of nowhere until Friday. While I'm mostly disconnected from the internet, I've still got my laptop with me and gear is moving forward. If anyone is interested in helping out, everything from stress testing to developing would be much appreciated.

I could possibly help out.

Count me in also, if I can help i would. I do not know anything about programming but i can do testing.

Ok I'll be home tomorrow before noon, and after lunch/the evening I'll be free for testing and taking suggestions on what to improve from testers. (Let us decide on a more specific time!). In terms of improving remember we're not really trying to imitate some plane, but rather trying to produce something new and better.

I will also be available the same times either saturday or sunday (not decided yet), so if you guys add me on msn we can discuss it. ancient[underscore]banana[underscore]tmuk[at]hotmail[dot]com

Don't try to use that for emailing though cause it actually isn't an email address :).

I'm hoping GG also will have time and perhaps also some other 44th guys. I'll see if some rve are up for it though I think we're kind of inactive nowadays. Any other squad that wants to test/help out will of course be welcome.

So guys, anyone up for some testing?

I'm on msn right now and will be for the rest of the day

Sorry i was yesterday little off-time but today i be on MSN all day and ready for some testing.

Did some testing yesterday, luckily at least GG was around to help :P.

We've decided that there is at least one tricky decision to make before moving on.

What kind of symbols should we use for what kind of contacts? :/

Right now I have my own symbols but GG prefers http://www.baesystems.com/ProductsServices/bae_prod_eis_mids_terminals.html (and the problem is that THAT small picture is basically all information we've got there), though I don't know how to represent all types of targets with that.

Basically these need to be easily distinguishable and easily remembered/intuitively understood:

* My scan contacts (1 type of symbol)

* My designated contact (1 type of symbol)

* My designated primary target (1 type of symbol)

* Datalinked scan contacts (1 type of symbol)

* Datalinked designated contacts (1 type of symbol), comes with id of wingman number or name

* Datalinked designated primary target (1 type of symbol), comes with id of wingman number or name

* All the above must have 1 friendly version and one non-friendly version. Perhaps 3 versions (F, N, E)

So we need at least 12 types :P

All help and suggestions on this is helpful

May I make a suggestion?

The last time I checked LEAVU2 (and perhaps things have changed since then) the exported data is streamed with a carriage return after each item. I suggest that each 'group' of data be exported as comma separated values with a carriage-return at the end of the group. There are two reasons for this suggestion:

1) it is easy to parse the lines by eye, as they fill a line, and

2) if one piece of data is corrupted on a line the other lines are not affected (unlike the on-per-line streaming where a single corrupted value affects all subsequent value).

I implemented this in my own version of LEAVU2 (when I extended it for mechanical data flaps/hook/gear) and it works fine.

You can keep the same shape but maybe play with colors or with lines. Something like all scanned contacts by your aircraft are in one color and all contacts scanned by wing-man in another color.

May I make a suggestion?

 

The last time I checked LEAVU2 (and perhaps things have changed since then) the exported data is streamed with a carriage return after each item. I suggest that each 'group' of data be exported as comma separated values with a carriage-return at the end of the group. There are two reasons for this suggestion:

1) it is easy to parse the lines by eye, as they fill a line, and

2) if one piece of data is corrupted on a line the other lines are not affected (unlike the on-per-line streaming where a single corrupted value affects all subsequent value).

 

I implemented this in my own version of LEAVU2 (when I extended it for mechanical data flaps/hook/gear) and it works fine.

The data export has been somewhat cleaned up, but not the way you have it, however I might change it.

The sim client is also modular so it can be replaced depending on what sim you are using. (for example x-plane would likely be different)

My FC scripts export one message per lua iteration/simulation frame

* Each message now starts with a header, containing a "key" string and a message size parameter (in bytes/characters).

* TCP transmissions, so I don't implement any own checksum. We should not see any corrupted data if I understand this correctly. (during so many hours of use in both leavu and gear Ive never seen any)

* Each section begins with a key

-- Finalize the data going out with a header
data = table.concat(data);
return string.format('%s%s%s%s', '!!dnacv02mJ8onvalPD893HNid8V9h6782sdu!!', string.len(data), '\n', data);

preferably each sub section should also have a size or ending, but currently they dont.

I still use '\n' as a separator for my stuff. But you can ofc replace it.

So basically u can map it like this

read byte[] bytes = getNewBytes.

find key "................." in bytes

parse integer after key -> numBytes

read numBytes and parse those.

catch me on msn and we can discuss it

If I make any significant changes it might be to change to xml instead. I'm already using that in gear for presets.

You can keep the same shape but maybe play with colors or with lines. Something like all scanned contacts by your aircraft are in one color and all contacts scanned by wing-man in another color.

it is how i started, but it becomes difficult to iff with this I've found.

Still, it's what I have right now.