RvEYoda

AS the AF flight model only has 2-variable tabulations afaik. We are talking about 8-Variable equations.

1000 points is an example Let's say you want to spend 1GB on FM data in your RAM. Each entry is one float, so 4 bytes. That means you can have at best 250 million entries. 250 M ^ (1/8 ) gives that (under the assumption that you have as many points on each dimension) you can have 11 points per dimension. Your plan is then to have varying density throughout the dimensions, using some algorithm to find where it is most suited? And then you plan on having some pretty interpolation ?

Well that is a problem, isn't it? If you have a function Cn = F(α, β, r, p, δh, δa, δr, δlef) as tabular data, you will require more storage space than is available on all harddrives in the world together.. One dimension per variable, 8 variables, 1000 steps per dimension, requires 10^24 entries.. I'm saying tabular data would be fine if we could store it, but I'm also saying, there is no way we can store all that data. Or am I missing something? --------- Edit: You know what would be a cool idea for a flight simulator? You have a small miniature USB-wind tunnel and you put in the model of the plane u want to fly :P

Great that you wanted to step in here Mav-jp. I have never seen the equations myself, but made the assumption that the calculation of drag/lift coefficients could not be reasonably simplified/approximated as two-variable functions (Your 2D tables). Naturally you can make N-D tables and you end up with just as good results as with a solver, but the problem then is, you have resolution 10.000 pts per dimension and 4 dimensions? You wont even have space on your harddrive for enough points. In order to solve any such equation (assuming it requires 4 or more variables), you need to solve it, in real time and not use table data. Now assuming that some of these equations can be reasonable simplified to 2-variable functions (again I have never seen these equations or studied aero/fluid dynamics, so I just draw conclusions on the two different cases) then of course the tables work :P.

That would be very helpful. A lot of people would appreciate it :) :pilotfly:

I'm running an E8400 and 4GB ram, but it seems that is not enough :(. I think even with an i7 I could not get more than 16 fps while exporting the texture at my current resolution. When playing for example Open Falcon I was told it is possible to export both MFDs at real time/high fps using shared memory, so I had assumed it was also possible in DCS. I guess for DCS we should use the ingame settings for rendering on other monitors instead? Maybe there is simply no need to export the textures through shared memory (I'm using the wrong approach).

. Ok I think it must be doing the right thing, but I get seriously low fps export.lua: function LuaExportStart() LoSetSharedTexture("mfd1"); end function LuaExportAfterNextFrame() LoUpdateSharedTexture("mfd1"); end function LuaExportStop() LoRemoveSharedTexture("mfd1"); end LoUpdateSharedTexture Seems to be killing fps. It goes from 60 -> 8 fps if I have that line there. Any advice on what I'm doing wrong? Once I add the second program to read the shared memory, that doesnt affect fps at all. Cpp test: #include <iostream> #include <conio.h> #include <Windows.h> using std::cout; using std::endl; unsigned int SR = 0x0004; HANDLE hfile; DWORD written; RGBTRIPLE *image; BITMAPINFOHEADER * bihPtr; int main() { hfile = OpenFileMapping(SR, false, L"mfd1"); if (hfile!=0) { cout << endl << "Grabbing data from handle: " << hfile; LPVOID memoryPointer = MapViewOfFile(hfile, SR, 0, 0, 0); if (memoryPointer!=0) { cout << endl << "Got memoryPointer: " << memoryPointer; bihPtr = (BITMAPINFOHEADER*)(4 +(long)memoryPointer); cout << endl << endl << "biSize " << bihPtr->biSize; cout << endl << "biWidth " << bihPtr->biWidth; // Will output the width of the bitmap cout << endl << "biHeight " << bihPtr->biHeight; // Will output the height of the bitmap cout << endl << "biPlanes " << bihPtr->biPlanes; cout << endl << "biBitCount " << bihPtr->biBitCount; cout << endl << "biCompression " << bihPtr->biCompression; cout << endl << "biSizeImage " << bihPtr->biSizeImage; cout << endl << "biXPelsPerMeter " << bihPtr->biXPelsPerMeter; cout << endl << "biYPelsPerMeter " << bihPtr->biYPelsPerMeter; cout << endl << "biClrUsed " << bihPtr->biClrUsed; cout << endl << "biClrImportant " << bihPtr->biClrImportant; } else { cout << endl << "Could not map memory handle to memory address"; } CloseHandle(hfile); } else { cout << endl << "Could not find any shared texture"; } _getch(); return 0; }

Sry to be a thread necro, but, I'm going to start ot use this very soon. I have never used shared memory before in any application. Am I assuming correctly that DCS sets up a shared memory space when I first call for example LoSetSharedTexture("mirrors") Then fill it with some information using lua: LoUpdateSharedTexture("mirrors") After that I can grab the file handle externally with: OpenFileMapping(SECTION_MAP_READ, false, [b][color="Red"]"mirrors"[/color][/b]); When the game closes I use LoRemoveSharedTexture("mirrors") Do I also need to close it externally?

Ok updated the list

I think it is used to set up 6DOF settings on many servers.

Wait I thought server.lua was automatically exported, it isn't? Are you saying you can also export config.lua?

After I saw this post I thought it would be useful if we created a complete list of lua files which are automatically exported from server to clients. This is important for servers to be able to include various custom settings, especially since RvE is going to set up an Fc2 server quite soon on a 100/100 connection. Currently I know very little of which files are automatically exported, but here is what I know so far. Automatically exported files: Scripts/Database/db_sensors.lua Scripts/AI/Detection.lua Config/View/server.lua Lua files that can be included in mission file: config/export/config.lua (<51>Case) config/view/server.lua (<51>Case) config/view/view.lua (<51>Case) So if anyone wants to pitch in and help me and others figure out which are the other files, it would be great! If you make a post saying you know one more, i will add it to the list!

120C is locked to be virtually immune to chaff. There are other reasons why they lose lock. The most common reason for any of these missiles to lose lock is because the target enters the doppler notch (beaming below the radar emitter, in the ARH case that is the missile itself). Further, the 120C and 120B have different flight energy characteristics, different drag and burn time, so they will have different speeds and approach the target from different angles (different results for proportional navigation). This means while the 120C may be notched, the 120B can be approaching from a different angle which isnt notched. Of course the other way around may happen as well. Third, the 120C has a higher loft angle than the 120B, and in many situations this actually prevents it from keeping a lock as good as the 120B. The 120C will simply be easier to spoof by notching under those conditions. All the stuff I wrote here is an explanation of how the game works. I make no claims to say "this is how it is in real life". If you really want to make sure you are going to hit your target; approach from below and fire once he gets close to Rtr. Then he will have a really hard time to escape the missile, although attacking from below has its own disadvantages ;)

In the previous versions there were some issues with turn rates; I think TR was calculated from magnetic headings instead of from actual 3D turns. Have you looked into this? How is turn rate defined?

I run the same (almost) 27% pitch curve & no dead zones, the rest is linear.

I could be that my msword cannot handle cyrillic properly, but it seems that all the text is made out of text boxes, and some of these are on top of each other.

I simply could not use the X65 throttle. I have medium to small size hands, but as soon as I try to move the throttle backwards or forwards I accidently hit a button/hat/switch on it. There does not seem to be any position to keep my fingers relaxed. The stick is better, but still the shape feels unergonomic in ways, and maybe you saw that centering issue, I experienced the same the times I tried it (Significantly missing the center position). On top of that I could not get very good precision, but that may just have been badly set up maximum force. Maximum force was not enough. Even when using the highest force level required, it was too easy to reach maximum ingame deflection of control surfaces (I tried it with Fc2). I was expecting a result like "ok now I want to move my FPM one pixel up on the hud", but I found it not to be possible with the X65 setup I used, whereas with the FSSB it was not a problem at all.

yes now we got something in the middle :P u->0 u->2 0<->1<-2 it would be good to also have u->1 0->1->2 0<-1<-2

It didnt work? Have your remapped your ingame keys? OK maybe you do need a 0.1 s delay between key inputs? Because I just used these commands myself and they seemed to work fine Check carefully what buttons you enter, note I did not use the same command as h00t74 ------ Motivations Unknown -> no flaps: Press "flaps up" Unknown -> flaps 1: first press "flaps up" (flaps intended position is now guaranteed full up), then press "flaps toggle" Unknown -> flaps 2: press "flaps landing position"

Oh, so you want to increment 1 step and not set a specific state I see. I thought you wanted to set flaps to specific state "1 step down" :)

check http://forums.eagle.ru/showthread.php?p=904265#post904265

Hmm, ur right, I just tested it. However you can still create a joystick button that sets your flaps to 1 notch. Unknown -> no flaps: LCTL + F Unknown -> flaps 1: LCTL + F, F (joystick macro, you don't need any delay) Unknown -> flaps 2: LShift + F

I get problems when I open the doc in msword: Pages 12, 13, 14, 17 and 18 has text is on top of other text Pages 13, 14, 17 and 18 has pictures on top of other pictures Table of Contents start at 1 but doc starts at 3. Please take this attached file, you can use it as source code/initial document to translate if you want to and get time. You will need Open Office. LE21.zip

Tried it, the stick gets a 3/5 and the throttle gets a 1/5 from me. I'm sticking to my cougar FSSB R2 with good old X52 throttle :) Works like a charm in BS too (possible to hover and turn inside hangars)