The future of LEAVU, a more general tool?

[GGTharos]

Use the symbol itself: Solid line: Your own hit, dashed line: Datalink only.

 

Filled symbol is targeted.

[RvEYoda]

Use the symbol itself: Solid line: Your own hit, dashed line: Datalink only.

 

Filled symbol is targeted.

 

Had the same opinion myself earlier but I've come to the conclusion that too much dashed stuff = baad :). Clutter. A previous suggestion here though with half icons for dlinked stuff I like more. Hollow/filled is also good. (perhaps it is why those things are used irl? ;)). Also dashed is bad from a programming point of view when you got different display sizes, resolutions, etc... Zoom levels and so on. Certainly it is doable, it's just ugly code though :P

Edited August 17, 2011 by =RvE=Yoda

[Presing]

Smart a**

 

... Hollow/filled is also good. (perhaps it is why those things are used irl? ;)). Also dashed is bad from a programming point of view when you got different display sizes, resolutions, etc... Zoom levels and so on. Certainly it is doable, it's just ugly code though :P

 

If you know evrything why you asking question's :P. Just joking.

Anyway in real life you will have two contacts overlapping on the radar screen and they difficulty saying what is what.

[GGTharos]

In real life you won't be able to tell that it's too contacts if they're inside the same radar cell. If they're not, there are radar modes to help you break them out :)

 

The APG-63v(0) for example was capable of 1/4 degree resolution at 40nm using RGH, IIRC. This means that to break out targets at that range, they would have to be spaced at least 330m apart, otherwise they would appear as a single contact.

 

If you know evrything why you asking question's :P. Just joking.

Anyway in real life you will have two contacts overlapping on the radar screen and they difficulty saying what is what.

[RvEYoda]

If you know evrything why you asking question's :P. Just joking.

Anyway in real life you will have two contacts overlapping on the radar screen and they difficulty saying what is what.

 

Oh? So we should just "Oh it's difficult, so let's leave the subject"? :). Maybe we should give the pilot extra difficulty by just drawing white dots for every type of indication ^^. Just kidding. I previously in this thread first said "I will not go back to leavu symbology", and now I say "I will take suggestions and discuss what is required, but leaning towards going back to MLU/leavu symbology".. .Why ? Because it's good :) and I cannot figure out something that is clearly better. Why should I be stuck on one opinion if I see another solution is better hehe... I hate the idea of fighting for a subject even when you know it's wrong :P.

 

If you have a max zoomed out hsd for whatever reason, you should strive to make the symbology on it should be as clear as possible (cause it will all be very...cluttered!). There are a ton of reasons why radar resolution should not matter in this case, for example: the contacts may be displayed at whatever icon/range scale settings you wish, resolution, sizes, the contacts/data may not even originate from a radar with such limitations, or a radar at all!

 

Right now howver, I've come to the conclusion that I must invent a new programming style/access rights patterns for general multithreaded applications ^^. Overkill for gear? Yes, but it is self education and necessary to convince myself of some things :D. So far my best solution is a thread-type analoge to private/protected/public, which I so far call "shared" (both a generalization and exension of (reordering preventing) atomic variables/volatiles) - I feel there is a large gap between low level synchronization primitives and thread<->thread message passing architectures that needs to be filled.. the latter is simply too slow for some high performance applications and the former is too low level for many things. Essentially something even Java is missing, and is still stuck at C level on. I need to fool around and come up with a solution or find one online which basically takes the step for threads what Cstructs->C++classes.

 

EDIT: My first idea on a solution of this thread concept is (and all help out there is very gratefully accepted!).... is (this might sound strange), To instantiate thread access rules. This can sound strange. I'm not just instantiating the access primitives, but the actual rules themselves...more to follow :).

Edited August 18, 2011 by =RvE=Yoda

[Presing]

Bilbo Begins: I don't know half of you half as well as I should like and I like less than half of you as well as well as you deserve.

:D

 

Did not understood your post well but to get back to the matter of symbols. Maybe the best one is full and empty because it will work well or pretty well on almost all resolutions. Keep with good work and when you finish i would like to try that.

 

Best Regards

Presing

Edited August 18, 2011 by Presing

[RvEYoda]

:D

 

Did not understood your post well but to get back to the matter of symbols. Maybe the best one is full and empty because it will work well or pretty well on almost all resolutions. Keep with good work and when you finish i would like to try that.

 

Best Regards

Presing

 

Thank you. I will try my best. And sorry if I offended you in my previous post, it was only meant as a little joke in the beginning.

[RvEYoda]

Here is a sample of the new symbology I've been working on. Some is copy-paste straight from the F-16 MLU manual, but I have decided to make some changes. Maybe you can see what :9.

 

I also upped the symbol sizes by about 15% and reduced the osb button size by half.

 

[RvEYoda]

Had a little idea.

 

Implemented a sort of Instructor Mode where you don't send any information over dlink where you are yourself, but you can see where your "students" are ;). (Checkbox at the bottom of the main gui)

 

 

Oh yes and I solved that threading issue I had. I wrote a system that enforces thread safety at compile time by marking a set of variables as thread-shared, as a group. To access any of the variables contained in a shared group/object you have to provide it with a "Runnable"-like object (can be preallocated), which is then automatically performed as a thread safe operation.

Edited August 21, 2011 by =RvE=Yoda

[G3]

Looks great, smaller buttons was a good idea,

Should be good for smaller layouts.

Following gear with great interest,

 

Thx for all your effort and time so far Yoda.

 

Edited August 21, 2011 by G3

[RvEYoda]

Going to put some bullseye information in there, then the hsd page is basically finished (Well at some point i might implement that moving map here...but...that is for a later time ;)). Here with some ownship bullseye coordinates.

 

[elchacal]

Excelent work, thanks a lot for share it! :thumbup:

[Cali]

A moving map would be awesome, if this was allowed online I could hear the cries now :D

[Haggart]

I'm still available for some testing.. ;)

[RvEYoda]

Actually the above bullseye numbers are wrong, can you tell? :). They are inverted. Fixed now.

 

 

I'm still available for some testing.. ;)

 

PM me your msn details

Edited August 23, 2011 by =RvE=Yoda

[RvEYoda]

OK some updates on rendering performance. Here is what I've profiled so far.

 

PERFORMANCE ANALYSIS

To ensure JIT optimizations are mostly done, I let gear run @ maximum 
framerate on 21 simultaneous MFDs for about 30 seconds. About 450 us is 
required for 1 simple HSD frame (without any contacts etc) including 
opengl thread call overhead. 

- 250 us of this is OpenGL thread call overhead alone (hooking .display()), 
 so that I cannot fix (except try not using AWT windows for future instruments, 
 the JOGL guys recommend using their new GlWindows for this instead.)

- about 150 us seems to be calls to glDrawElements (This will increase
 when scene complexity increases, so might want to consider improving this,
 lowering shape complexity etc)

- The textrenderer seems surprisingly efficient now, requiring 
 less than < 50 us. (I was going at it with a big sword!)

- Performance costs of synchronization events in my own code are entirely 
 insignificant :)

 

These numbers are with fc2 running (default detail settings @ windowed mode 1024x768 ),

which means that GEAR's opengl calls will block/consume more CPU time (how opengl works),

so if I was ONLY running gear, results would likely be a decent amount faster.

 

Oh and the code is now Java 7 (Not java 6 compatible!).

Edited August 23, 2011 by =RvE=Yoda

[GGTharos]

No it can't be, because it can only operate with data from your own aircraft.

The datalink also allows you to collect information from other aircraft that are datalinked with you - so it functions pretty much like a real datalink. It doesn't know (does not need to know, cannot know because exports of everything are usually turned off anyway) the positions of everything in the game. Someone has to pick up and transmit a contact.

[GGTharos]

It is possible if the exports of everything are turned on (for example: See Tacview), but LEAVU does not require or use these even if they are turned on, and it will work if these are turned off. It works frome exported ownship data only, so it only knows what your virtual aircraft knows.

 

Roger. Well, my thought was, if the game does know something, which i cant see but its in the game, there might be a way to see or extract that info already in the game, therefore my question.

[RvEYoda]

Basically there are two ways to get data from the game. This capability was built into the game from the beginning and is nothing I've added. These kinds of capabilities exist in most other sims as well, like X-plane and FSX for example.

 

Global data exports: In multiplayer are turned off by default. You can see everything about everyone. Tacview uses this. Gear does NOT use this.

 

Local/Instrument only data exports: On by default (but most servers block these). You can gather data from your own instruments and for example send to your own external application. Gear/Leavu uses this. Drawbacks: There are bugs in the local/instrument only data exports that, in some conditions (see notes on ecm in main post), give you more information than should be available (These are bugs in the API supplied with fc, not bugs in gear). Gear intentionally masks these bugs, but because the lua is just plain text source code, anyone can go in and unmask them. (provided that we for example don't use IC on a gear variant of export.lua, which would enforce that masking).

Edited August 23, 2011 by =RvE=Yoda

[GGTharos]

*yawn*

 

Get off the paranoia bandwagon, we've had enough of it. There isn't even a way to detect a missile launch event even with global exports. It has to be hacked in and is not always reliable. Furthermore, you wouldn't know the missile's target without some fairly funky processing and frankly, if someone made that sort of MWS, they deserve to have it ;)

[RvEYoda]

When I speak about intentionally removing bugs/flaws that comes with lockon, someone suggests me of hacking into the game and exploiting it? Maybe one should claim that doctors are the worlds largest serial killers ? After all, they couldn't be trying to help anyone...

 

MATT ; you arent making any sense ^^

Edited August 23, 2011 by =RvE=Yoda

[RvEYoda]

People build wooden houses. Wood can burn, so there may be a fire. To be safe, should we stop building wooden houses?

 

The information in this thread is enough of information to clarify all possibilities I know of for gathering data from the game. These possibilities have not nor never will be introduced by gear/leavu - They were there from the start, explained from the start by ED and encouraged to be used for external applications (Go into your own vanilla lockon folder and read the export.lua file)

 

The conditions have been given: *THIS* is the data available. There is no way any person in the world can imagine all possible ways to use *THIS* data (Therefor any question such as "Can this data be misused?" is totally impossible to answer.). That is why science is not final, someone thinks of a better way to use available data. Will you come back 3 years later and say that the information given to us by ED, which I used to produce product X, was not the cause for someone producing product Y completely in parrallell? That X itself produced Y?

 

- Gear/Leavu NEVER exposed any extra data from the game.

Edited August 23, 2011 by =RvE=Yoda

[Cali]

*yawn*

 

Get off the paranoia bandwagon, we've had enough of it. There isn't even a way to detect a missile launch event even with global exports. It has to be hacked in and is not always reliable. Furthermore, you wouldn't know the missile's target without some fairly funky processing and frankly, if someone made that sort of MWS, they deserve to have it ;)

 

:chair:

 

He is asking for a reason, cause people have done things like this in the past. Servers don't allow tacview cause they think that people can cheat from it. The workaround for tacview works but it is a pita, would be nice if it wasn't disabled. There is nothing wrong with him asking, you 2 of all people should now.

Edited August 23, 2011 by Cali

[RvEYoda]

:chair:

 

He is asking for a reason, cause people have done things like this in the past. Servers don't allow tacview cause they think that people can cheat from it. The workaround for tacview works but it is a pita, would be nice if it wasn't disabled. There is nothing wrong with him asking, you 2 of all people should now.

 

Look, I have no problems with people asking questions. You asked some questions and I tried to answer them as best as I could. But some people intentionally misread posts and intentionally ask their question in such a way to much and provoke, with little interest in an actual logical answer. Take for example the post by "MATT" about "masking". He completely (probably intentionally) misinterpreted the post and said something that had nothing to do with what I or gear did. In my post, I tried to explain that the lockon lua API, in some situations even for local sensor export, exposes too much data. Gear does not use this "unrealistic" data, that is not the intention. This is what I call "masking" this data. But someone else who writes an "unfair" data extractor could. In turn, after writing this, he said that I was masking data/problems/yadayada - He had either not understood my post (fairly possible he does not understand any of this) or was just after spreading bad stuff/provoking (also possible).

 

On top of that it is very possible we know this person who is asking these "questions".

 

Now the simple answer is (as already answered), that "MATT" said I *danced around*, I don't know if it can be misused. What is misused to you? I could change that to two questions (and I believe I did in an answer in a previous post to you).

 

- How can the Fc2 Lua API be misused? - I can't answer that more than already done.

- How can Gear be misused? - I have no idea. First define what you mean by misused. Unlike leavu, gear development does not care if the instruments rendered are the actual aircraft's realistic implementation. Gear only cares about making the best instrument with available data. The available/used data however, must come from realistic sources!

 

We can speculate further, can we come up with ideas to misuse it possibly?

 

- If I answer with a list of possibilities that I think most people would dislike, then people will think I hunted these possibilities, misused them, and now I'm spreading exploits like crazy. Also I would not be telling the truth because nobody can know all the ways you can misuse information/data coming from your aircraft's sensors.

- If I answer that I don't know, you think I'm hiding something.

- There are dangers far worse than just extracting "unfair" game information associated with this, things that we should definitely not spread around.

 

If you want a more precise answer than this, you will have to ask more specific questions or reformulate them in such a way I can answer them. There is simply no way I can know all ways the fc2 lua API can be misused. I did not invent it, and whoever did could not answer your question anyway :P.

 

- For example: you can already have a TEWS with touch buddy which gives you more information than the standard tews, and the touchbuddy tews I think works with any aircraft, not just f-15 and A-10. The data source is the lockon lua API, not gear :).

 

And tbh, I don't really need to answer any questions about this. I could just sit quiet. Some people think I am useless as a vpilot without these tools? Well go tell them to go win LLTM (and finish 3rd next year), Fortis cup(or today's equivalent) and go build simulators for real applications (mil and/or civ). I do also believe I performed decent in the Fc1 locerfs.

 

And nobody is forcing anyone to allow gear/leavu on their servers. Just slap vanilla export.lua IC on there and they're all blocked. I however, have some cool plans for a server of my own, which will force you to join datalink among other things :).

Edited August 24, 2011 by =RvE=Yoda

[MoGas]

:chair:

 

He is asking for a reason, cause people have done things like this in the past. Servers don't allow tacview cause they think that people can cheat from it. The workaround for tacview works but it is a pita, would be nice if it wasn't disabled. There is nothing wrong with him asking, you 2 of all people should now.

 

Well, if someone wants to cheat, he will cheat anyway. After a while of FC2, without the first version of LEAVU on the server`s, after it was hunted down by a group of people, it showed us that some loosers are still been able to cheat with export.lua is checked and tacview is blocked and so on. What I mean is, if someone needs to hack the game, and is able to get over the checked export.lua file, dosent need Yodas LEAVU.....to be looser....