RvEYoda

There are things that can look very similar on the surface, but the reason behind them, will often be entirely different - This is about lua APIs, exploits, cheats etc. I have already given the answers I can in previous posts. Sarcasm and provocations are things I feel are somewhat abundant in previous posts. This may not have been your intention, but I am not the only one feeling it. I already gave you answers to your questions. If they are not enough, than I am not capable of explaining it to you. If someone wants to list, the specific flaws of the data export APIs, that is a different matter (For example table returned by function X should mask members Y,Z given condition ...). That can be done and should help ED (I have already sent messages to them about where I've found too much data is exported). If you are "FULLY" aware, give an example, because you have yet to convince me you know 1 line of the API. I'm actually thinking of taking this one step further for a "special" server, auto-disconnecting you if you don't connect to the proper datalink network in a given time limit. :)

Sry, i realize what I said sort of suggests you meant gear. That was not my intention. Gear talk from the work desk :? Just wait, when I get my 3d radar and rwr out there :p. Maximize instrument capability from standard data ! :D

Agree with you, but, I don't think GEAR/LEAVU actually makes it easier to cheat. Unless you consider gear/leavu to be a cheat itself, I can't help you there ^^.

That just sucks. Some people are just interested in making life worse for everyone else.

oh, someone found a way to break IC?

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 :).

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.

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 ^^

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).

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!).

Actually the above bullseye numbers are wrong, can you tell? :). They are inverted. Fixed now. PM me your msn details

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.

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.

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.

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.

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 :).

Hey which building is ED located in? I would like to say hello but I couldn't find them today. (That is if ED is there this year, but my friend told me they have been there before)

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

Small extra symbols placed nearby have a few problems though... They clutter things up a bit more plus it becomes difficult to tell what is going on when two guys are on top of each other. In these cases I prefer different colors. In priority of what is most important should be (imho): IFF, Source, lock/search type I have been away for a while, and I'm still not home (in Moscow atm), but... I am moving in the direction of making F-16 mlu type symbology with certain additions on my mfd instrument (Basically 85% the same as leavu symbology). You are of course free to add whatever symbology you like on other instruments you make for gear :).

Flew a 4ship today on 44th teamspeak and talked about some things. Didn't really find any bugs with the software, ran silky smooth and well. Though we did implement a new bandwidth control which allows you to set your maximum allowed datalink upload limit. The update rate of the datalink will then adapt to match this. After a bit of work (messing around with tcp sockets) we were able to get high fps datalinks working on pretty low bandwidths. The Only important thing is to have a dlink server capable :).

PM me and we'll get you started.

If someone codes that instrument, sure. Though I myself have no intention (at least now) to do this, anyone willing is free to add such a capability/instrument to the gear software and we'll add it to the official release.

Ok I've generated 3 zoom levels of test PNGs. 1. squares with approx 20 nm sides 2. squares with approx 60 nm sides 3. squares with approx 180 nm sides If you want to see the test images you can have a look at http://www.gigurra.se/GEAR/maps I did some manual work here, so I will at some point start working on an automated method of generating all zoom levels. EDIT: Furthermore it might be pointless to use squares with sides < 50 nm. Turns out when using those small squares all you get is smooth data anyway, so I might just start with 50 nm squares and let opengl texture scaling do that smoothing instead of storing all those points. Compare the two images below. Can you tell which was recorded 1200x1200 on 20nm squares or 60 nm square? You prob can but there's not a huge difference.

Unfortunately that compression is not enough compared to png but i will use it to lighten the load a little. Consider I have a couple of gigs (>5) of data and S3 does 4:1 compression (It's static 4:1 afaik), pngs are more like 100:1 in these cases (due to lots of zeros), therefor I cannot cache the entire map to video mem on the highest resolution. Right now I've run into a problem when calling getAltitude in lua. I seem to get Square::findTrg(534, -444053.093750,740324.687500) - cycle Square::findTrg(534, -444083.687500,740355.437500) - cycle Square::findTrg(534, -444114.312500,740386.125000) - cycle errors when calling the function on certain coordinates (not outside the map boundries afaik). I'm guessing this means that some internal ED C function is failing, though I don't know what I should do about it. Is there anything like a try/catch block in lua so that I can use some kind of fall back method here? Annoying to be half way through a "world scan" and bing......problem causes the entire scan to abort with that message. EDIT: nevm that doesnt seem to be what's causing the problems...hmm. EDIT2: Nevm, problems solved. Two problems. Lockon was running out of memory (saving 1.4 mil points in text format and concatenating them into 1 string is apparently bad, solution: reduce number of decimals). Problem 2: it stopped reading back subsections after 31, Solution: Increase parameter "maxSections" :)

Actually thats just a raw 16 bit greyscale image in Java, but Java has standard Imagewriters for PNG format among others, so that part is simple. The hard part will be after that - finding a way to efficiently select which images to load/unload to/from textures given the original pngs data without killing all available memory :P. Fortunately I was yesterday able to figure out how to make OpenGL share resources among different contexts so at least I will only load stuff once to the gpu, even though multiple views/mfds/instruments could be using it. (GEAR uses OpenGL for rendering)