Moa

Good points jireland607. Although even if an Application Programming Interface (API) was *not* FREE it is still legal to either implement the interface or connect to the interface using a non-copyrighted implementation. I'll also take this chance to clarify about encryption. The DMCA prevents breaking encryption in order to circumvent copyright protection. Decrypting non-copyrighted data from a hardware device is probably not protected by the DMCA.

> you need to use NP software to decrypt it legally AFAIK, this is not correct. Outside of the US (due to DMCA) you can use any program you want, just not Natural Point's software (unless you want to be bound by their license). > the problem isn't making conpatbility with TIR HARDWARE, the problem is making compatible with TIR SOFTWARE Also not true. Reverse engineering is allowed. You can easily, and legally, insert interceptor methods that bypass the NP software and call your own - and this will appear to all programs as if the NP software had been called. Memory allocation debugging tools (and OpenGL debugging tools) do this kind of interception all the time.

@Wolf Rider. Copyright only applies if you make a copy. In this case you cannot make and use a copy of Natural Point's software unless you agree to their license terms (the license is an agreement by NP to suspend their copyright claim under certain conditions). If you make software that is compatible with TrackIR hardware (permitted under 'reverse engineering for compatibility' provisions in law & case law) then you are not infringing on NP's copyright and their license does not apply. This has been used by several Open Source/Free Software projects to produce compatible implementations of software (Samba being an excellent example). However, since the NP software now uses encryption it is protected in the USA by the Digital Milinieum Copyright Act (designed to keep businesses models from the millennium that ended on the year 2000 going, rather than update copyright for uses in the millennium that started on 2001). Implementations outside the US are not affected (although WIPO treaties are eroding these protections). So, it would be a huge Pain In The A$$ for ED to move away from the NP software. However, NP does not give ED money (that we know of), its civilian customers (and military contracts) do. If there was enough demand (that is, sales) for it I'm sure ED would consider enabling webcam head-tracking as well as TrackIR tracking (just not using Natural Point's software). Natural Point is unlikely to have any legal basis to prevent this.

Yes, but if you write software with similar functionality you don't need the TrackIR software. Many years ago I developed an application with the TrackIR SDK - it was a medical application where head and eye tracking was required. The TrackIR solved the head part. The SDK is pretty simple (from the outside, and what it is doing internally is not that hard, hence all the Open Source equivalents springing up). In fact, most if the hassle with programming the TrackIR is getting you license key registered, otherwise TrackIR refuses to work with your application (more bollox from Natural Point). Game companies are waking up to the fact that there are alternatives to being locked-in; 'exclusive' is generally a bad word in business (you don't want an exclusive supplier, as in this case; or as a supplier you don't want a client that demands exclusivity).

There is a misconception that there is a legal construct called "Intellectual Property". This is incorrect, there is no such construct. It is a useful 'umbrella' term for the following legal constructs: * Copyright * Trademarks * Patents * License agreements. This is not me being pedantic, it is trying to get the discussion based on how the legal system works, rather than a undefined and nebulous term (good work for bringing it up Panzertard). Copyright does not apply here, as no Natural Point (NP) code or executables would be required. Trademarks do not apply, unless you use terms and colours which are similar to NP's. Patents may apply in the US. They may or may not apply for compatible hardware. In much of the developed world they do not apply for software (although the sneaky ACTA trade treaty is being pushed by the US Government to try and get their trading partners to kowtow to the US system/corporates). So we are left with the End User License Agreement (EULA). This cannot override the laws of the state you are in (and different sovereign states have different laws, of course). Most developed countries (including the US) have laws that explicitly allow reverse-engineering for compatibility reasons, and this has precedent cases which have ruled it is allowed. Therefore, despite what the EULA says its provisions are not guaranteed to be enforceable. If you can prove you are only trying to make a compatible implementation (which appears to be the case here) then NP are unlikely to get a court ruling that would stop you. What they can do is be a nuisance with suits (which cost a lot of money until the court rules in your favor) and exploit the fact they have deeper pockets than you. However, they would probably try and get you to settle (pay them) out of court, as they would be aware that if the enforceability of their license provisions were ruled on in court then an unfavorable ruling would mean everyone else was covered by the same ruling. In short, you could build something with a compatible interface provided you didn't use any of NPs files (not even their header files provided for linking, you have to get the signature from the DLLs). Compatible 'cleanroom' independent development is pretty much always allowed. Disclaimer: IANAL (not a lifestyle choice - webbish for "I am not A lawyer", I just read Groklaw from time to time). If you have doubts then engage a lawyer and see what applies in your own country/state/jurisdiction. nb: unauthorized copying the Natural Point software (or LockOn) is not allowed, it is covered by Copyright (so don't do it!).

@winz: nb: theOpenGL-vs-DirectX comments by Carmack you talk about are as out of date as the comments he made in 1997. Here is why ... They were made when OpenGL was stagnating and not matching DirectX for features. Ever since the Khronos Group have taken stewardship of OpenGL it has leapt ahead - to the point where it matches DirectX. There are also features where OpenGL is ahead (and vice versa), eg. better 'picking'. So, if OpenGL and DirectX have similar-enough parity in terms of features you might want to consider OpenGL for the following reasons: * OpenGL is generally considered easier to program. DirectX since 9 has slowly been converging to a model similar to OpenGL, but OpenGL is still much easier to work with, IMHO (doesn't have as much Windowsesque cruft). The OpenGL fixed functionality pipeline is easier, and for more modern work GLSL is nicer than HLSL. Please note that I do OpenGL programming, so it's not just something I read, it's something I use as a developer (in fact, I hope to show some of my hobby work in these forums next week - and it will be OpenGL based). * OpenGL is cross-platform. Not just Linux, but Windows too! and Macs, and Android, and iPhone, and PS3, and Unix, oh yeah, did I say Windows. OpenGL works on pretty much everything except the XBox (where it could, but Microsoft have deliberately keep it out). Think cross-platform doesn't matter? Well, choosing it made $3.5 millions dollars personally for the creator of X-Plane when it was ported to the iPhone - something he says he couldn't do if he had chosen DirectX. Please see: http://techhaze.com/2010/03/interview-with-x-plane-creator-austin-meyer/ In fact, true cross-platform (not Microsoft's warped definition of 'cross-platform' which means 'maybe works between Windows releases') is going to be be *more important* in the future, not less important. The Windows PC is still important, and important for gaming, but the revenue fraction from it will decrease over time as consoles and phones/pads and consumer devices we haven't yet thought of are all emerging. These pretty much all run a flavour of OpenGL called OpenGL ES (which is essentially the same as standard OpenGL, with some features removed to get it into silicon). If OpenGL didn't work on Windows then the cross-platform argument would be moot, and clearly DirectX would then be better than OpenGL in an imaginary world where OpenGL didn't work on Windows. The fact is OpenGL works on Windows and everything else, while DirectX is limited to Windows (and version-limited with XP) and XBox. * As someone pointed out, OpenGL has an extension mechanism that standardises OpenGL access to particular features of your hardware. The equivalent in DirectX (at least older versions) is device capabilities, which are a pain to use in comparison, and make programming more complex. * There is more than one implementation of OpenGL. This is a good thing as it means if it doesn't suit one particular vendor's interest to keep developing it then other vendors will still provide it (eg. Mesa, Intel, Nvidia, ATI, etc - none of these are likely to evaporate soon). Here's one example, Microsoft don't do DirectX 10 or 11 features on Windows XP - the true reason for this is they want you to pay to upgrade to a newer version of Windows. Meanwhile, if you have the correct graphics card and OpenGL drivers you can get DirectX11-equivalent functionality on Windows XP if you want through OpenGL and OpenGL extensions. Not only does this mean gamers would not be forced to upgrade (they could move off Windows XP when it was convenient for *them*, not when it was convenient for Microsoft). For companies this forced upgrade can be significant sums of money for licensing, and even more for training. The downside of OpenGL is two-fold: * for a while OpenGL implementations got less attention than DirectX. This is changing of late, mostly due to the use of OpenGL ES in the rapidly-expanding gadget market. So, I think this situation is very likely to change. * some tools are DirectX only. This is mostly a legacy of the Windows dominance of computing (now rapidly fading). However, apart from game-oriented tools most professional graphics tools have DirectX and OpenGL implementations. This is because professional rendering shops (eg. like Weta Digital currently making the two Hobbit movies in my city) use huge clusters of Linux boxes (they're cheap!) to do the rendering, so OpenGL and OpenGL based tools are needed by the pros. DirectX has its place (mostly Windows-only gaming). Elsewhere it is an OpenGL world (which is not visible to most consumers).

very nice.

Very nice. Thanks for posting the link RED9|R1pper.

Cockpits are the biggest area of LockOn/DCS that are hard to mod (textures only at the moment). ED have been making more and more functionality available though, eg. exporting MFDs and Shkval. In A-10C there is also support (header files and example codec) of how to provide your own codecs for movie export. It was an unexpected bonus of ED to take the time to document that (thanks c0ff and crew). Slowly but surely we're getting more support. I would be nice to have the ability *now* to do these things, or even a declaration that one day the ability to access the DCS frame buffer would be supported. Hopefully it's on their frag-list of 'someday' wishes somewhere. I don't think giving direct access to the final framebuffer for compositing would be too hard - but without knowing the internals of DCS it's hard to know the possible gotchas (if there are any). However, it's clear the ED team are busy with their true priorities (expanding A-10C and bringing Ka-50 and possibly FC2 up to that standard). IMHO this is how it should be, as far more people benefit from the increasing features being added in the A-10C 'patches' (I personally can't wait for the self-shadowing cockpit in A-10C, scheduled in patch 1.1.0.8 I think). I do hope one day that we do get access to the DCS frame buffer so we can do composition (not only for cockpits but also I've love to be able to put things like US carrier PLAT camera cross-hairs and text in-game).

Well, Yoda did most of this work (synchronize radar with LockOn) with LEAVU2 (I contributed to LEAVU2 in a small way). I also adapted LEAVU2 to get the mechanical state of the aircraft and make a little display for arrestor hook state etc for carrier landing (since I often fly with VNAO). So this is entirely possible. Yoda also improved on the default F-15 radar model with his EFI mod - which made it more realistic. The HUD and MFDs are just pretty simple 2D 'textures' that get updated every couple of frames. Then texture map to the correct coordinates on the model. No big deal here. Even better, the HUD and MFDs are flat surfaces. Texture mapping spheres (which I've done in OpenGL) is more of a a PITA. The DirectX hooking is clearly possible, as shown by Kegetys' work. However, I think there is another way that this could be done. Lighting etc is also relatively simple. Shadowing requires more work but is also not that hard. Soft-shadowing is harder - so don't start with that. nb: looking forward to A-10C having self-shadowed cockpit (great job ED). Position of the sun would need to be computed (since LockOn uses realistic sun, moon and star positions - got on them), but there is no shortage of libraries for doing this. The tricky part is the overlay. Either injecting the cockpit into LockOn, or, grabbing the LockOn screen and texture mapping it as a background and overlaying the cockpit on top. Thinking about it I prefer this way as it gives more freedom for the implementation (and after doing a decade of Windows programming in the 90's I loathe doing it now, since non-Windows programming tools are so much more modern and nicer, even C# has vestiges of the old Windows cruft). For interaction you leave the joystick etc directly input to LockOn. Then your overlay intercepts all keypresses and translates to LockOn commands which are transferred through the LockOn input interface. That way the overlay can have input focus and you don't have to worry about giving it to LockOn. This would be much easier if it was possible to get the LockOn display as a bitmap in the same way that DCS exports it's MFDs/Shkval as bitmaps. If you are running out of things to implement (lol!) c0ff this would be wonderful. Edit: * would the radar model be DCS quality? of course not. But it could be usable to FC2 levels (and maybe a bit more). * of course rendering a cockpit externally would consume CPU cycles (just as well your quad core beast has two idle cores :)) and there would possibly be a FPS drop. The trick will be how much this can be minimized so that the game+mod is still playable. * Finally, once the technique is perfected there is no reason it could not be used for other cockpits. Tornado or Eurofighter anyone?

What is your particular problem? How to get a live HUD working and get the cockpit in the game? I would suggest the use of DirectX overlays rendering over the LockOn image. This is the same technique FRAPS uses for its overlays. I'm prepared to have a tinker next week as I've been dying for an F-16 for ages. Essentially you render the F-16 in an external program and then 'paste' the image into LockOn using an overlay. The external program uses the LUA export mechanism for communication with Lockon. In this way any cockpit can be injected into LockOn. Clickability would be tricky but should be possible.

I'm interested in (paying for) an F-16 model. Can it be imported into Blender (I don't have 3DS Max, it's too expensive to buy and I don't want to pirate it, so it would have to work in Blender)? As TOMCATZ says, a recent screenshot would be nice. john_x, please PM me with your likely price and conditions of purchase and we can go from there.

Regarding printscreening in combat. The 104th and =4c= servers (which have joint statistics) log all screenshots in multiplayer (they log *everything* LockOn gives). If someone printscreens before missile impact it can be reported and we'll investigate. I can't speak for the 51st server, but I guess they also do this. The point is, printscreening to dodge missiles is a risky business likely to get you banned on multiple servers.

Good analysis EtherealN. Plus, what is not given is the variance around the MTBF. A variance of 1.2 million hours would mean 66% of drives would die in two years. Obviously the variance would be much less than this, but without knowing it the MTBF is relatively meaningless. Also, existing hard disks have failure rates that are not normally distributed. The distribution is 'U' shaped with the second part of the U around three years (the front part is those drives that fail within weeks of being used). SSDs have great performance. The Intel X 320 series has excellent capacity, performance and cost. One thing to know about SSDs is that they don't do partial failures like magnetic platters. With a magnetic disk you can often recover data when part of the disk fails. With an SSD it is usually reliable (no partial failures) but once it goes, it goes, and you can't usually recover anything :( So make sure you make regular backups when you use an SSD!

Here I'll describe a fix that worked for me for with problems I had with multiplayer login, when I had a downloaded DCS version (pre-ordered during the Beta) and a later Steam purchase. Background I had a 'download from DCS site' version of A-10C installed and used to run it as a multiplayer client on my server ('stallturn'). Since I wanted to run a copy of A-10C as a server instance while running an A-10C client on another machine I needed to purchase a second A-10C license. So I bought a second license through Steam and installed it on the machine that have the 'downloaded from DCS' version on it. I could not get multiplayer working. I couldn't log in to the ED network. It would always give me spurious messages about invalid login/password/email address etc. These messages were in fact incorrect (once I changed the game key they worked perfectly). I did notice that the login panel had the key from the download version and not the Steam version - even when I started from Steam. There was no way of editing the key on the panel (it was displayed in a non-editable field) and I couldn't find any way to replace it. Since there is an (old) key in the Windows registry the Steam version of the game never asks whether the key should be replaced with the Steam version's key, and this appears to cause problems. This is what I did to fix it ... The fix - update the game key 1) Try and do a multiplayer login and record the key (if you don't have it written elsewhere already). The key looks like a groups of letters and numbers separated by "-" characters. 2) Open your Steam games library and select the Steam key. 3) Select "Digital Combat Simulator: A-10C Warthog" from the left hand column that lists your purchased games (the leftmost of the three columns). 4) Click on the "CD Key" option on the rightmost column. 5) The Steam game key willl be displayed. Choose the "Copy Key to Clipboard" option. 6) Copy the Steam key somewhere (eg. a Wordpad window). 7) Open Windows registry editor and search for the 'old' key from Step 1. You need to remove the "-" separators from the key before doing the search. 8 ) Replace all instances of the old key with the new Steam key (also with the "-" separator characters removed). There were two instances IIRC. You can now start A-10C and will use the Steam key. Register a new account on the ED network and you'll be able to log in to multiplayer. I found that this worked for me. I use the Steam license key on the stallturn server and use the key from my A-10C pre-purchase (Beta) on a client and they now work together without dropping out (ED network used to kick me off). Hope this helps some of you get going. A-10C is an outstanding sim.

Very interesting Case. Thanks for confirming my suspicions. I was hoping that it was something bone-headed I was doing but was forced to conclude that the LUA callbacks are quite unreliable. Hence, I'm re-writing my stats to rely more on the the non-callback log entries (not just as useful cross-checks).

Politics are not allowed on this server. Be *very* careful with statements like "Georgia attacked Russia" as this is a political statement not a statement of fact. The International community/United Nations consider South Ossetia as an autonomous (de-facto independent) region within the borders of Georgia until the annexation by Russia in 2008. Such subjects should be avoided in statements (The UN findings found that Georgia started attacking South Ossetia [in response to shelling of Georgian villages], not that Georgia attacked Russia - so please watch the accuracy of your statements). Otherwise, thanks for the information about the four new Su-27 squadrons.

Hi Case, you are probably already on top of this (you usually are), but the Scripts/net/events.lua on_kill() function can be used to watch when a player kills another player (doesn't detect launches though). With a function signature (mandated by LockOn) of: function on_kill(id, weapon, victim) You can get various details: local p = players[id] local side = p.side local unit = p.unit local callsign = player_info_noside(id) local coalition = select_by_side(side, _("RED"), _("BLUE"), _("SPECTATORS")) local aircraft = unit_info(unit) local task = unit_property(unit, 14) local victimName = bot_info(victim) or _("Unknown victim name") local victimSide = net.get_unit_property(victim, 11) or _("Unknown victim side") local victimUnit = unit_info(victim) or _("Unknown victim unit") local victimSkill = get_unit_skill(victim) local killerSide = net.get_unit_property(id, 11) or _("Unknown killer side") and weapon_info(weapon) will give the name of the weapon (although not always for gun kills; kills where the target aircraft was damaged but not killed outright and then explodes/crashes later; or, kills where the attacker was killed first and changed aircraft/exited the game). However, there is sometime some randomness where some of the values can be reported incorrectly by LockOn (eg. the killerSide is sometimes reported incorrectly, leading to false reporting of teamkills). So, within LUA you can tie weapon info to an aircraft type but only for kills (not launches). Of course, if you have an external program (such as your stats) you can easily (and much more reliably) correlate launches with aircraft and callsign (using the 'default' LockOn logs that are not written by the user-modifiable scripts). Then it is a matter of making the external program do a kick (eg. through a socket to LUA input).

You do know aircraft such as the Harrier II can carry the AIM-120? Why would it be so difficult to accept a MiG-29G could also? Incidentally, if you have seen HAWX you will know that adding slammers to any aircraft still won't make LockOn HAWX. Different from what people are used to, yes, but still nothing compared to the button-mashing fiesta of HAWX. Personally, I'm neither for nor against the mod - although a change is nice once in a while - and it seems to have made a lot of 'REDFOR' players happy, which is a good thing IMHO (even as a usually 'BLUEFOR' player).

Grimes, if you remind me at the end of the month I'll get you the flight hour data for the 104th server (actually you could do it yourself if you know how to import a SOAP Webservice into a spreadsheet - but I'm very happy to do it for you provided I get a reminder to do so).

Why use a Kinect? There are solutions that require only a measly webcam and the two CPU cores that DCS isn't using (assuming you have a quad or sextuple Core). For example, see "Predator better than Kinect": http://www.i-programmer.info/news/105-artificial-intelligence/2310-predator-better-than-kinect.html That's only the tip of the iceberg - there are a lot of free and open-source tracking solutions emerging. Most of them are here now, so no need to hold your breath for Kinect.

The 'P' key is good for use with VNC :)

Polygon counts are usually tiny in comparison to pixel counts on textures (especially when multi-textured is being used). Textures eat bus bandwidth like there is 'no tomorrow'. So textures dominate bus transfer. Polygons count for vertex operations which are also small compared to per-pixel operations (especially when anti-aliasing, anisotropic filtering or occlusion calculations are being performed). For each vertex in your polygon your shader will interpolate a lot of 'fragments' to produce one screen-space pixel. So texture interpolation, projection, lighting and filtering also dominate GPU processing operations (hence Il-2 CoD is struggling with its screen space ambient occlusion operating on per-pixel operations using textures, normal maps and materials). Will be very interesting to see your numbers Kuky when you find time to make that run with constant CPU affinity.

What speed is your RAM running at? With lots of units that can be a bottleneck. Part of the reason a new CPU would seem faster is that you would also be doing a motherboard and RAM upgrade. If your bus changes transfer from 6400 or 8500 MB/s to 17066 MB/s it often allows your CPU and GPU to run at full speed. That's why your trusty old Q6700 can mostly handle it, it is probably idling while waiting for stuff to come across the bus. Your Radeon is pretty powerful and probably also idle half the time waiting for data to come to it. You can tell what your CPU is doing using the free CPUZ program. Run it and see what the cores are up to. If one of them is pegged at 100% then there is your bottleneck. Most likely it won't be that. Then get the free GPUZ program and see what your GPU is doing. If it is at 100% then that is the bottleneck. Most likely it won't be that. If neither your CPU or GPU are running at 100% then the chances are that your bus transfer rate (RAM speed and size [how much you can buffer]) is the culprit. If you upgrade you can spend less on the CPU (although the i7 2600k is relatively cheap) and divert any savings into the fastest RAM and motherboard to support that RAM. Later, you can upgrade the CPU when you have more funds (it is cheaper to upgrade the CPU after getting a good mobo and RAM then get an expensive CPU and be bottlenecked by mobo and RAM or pay to upgrade both later). Don't forget to post to this thread telling us of your experience. Good luck.

@goldfinger35: You must have missed the earlier survey about the community choice. F/A-18 was selected by about 2/3 of the community. It was the same proportion in a similar survey performed on the 104th Phoenix squadron forums. The F/A-18 may not be your personal preference but it is for plenty of folk. Just so you know. That said, no matter what ED do it'll be awesome. The realism is what makes it awesome (for me at least) even more than the platform (although I personally have my fingers crossed for an F/A-18).